The evidence: a full Article 14 gap audit of my own firmware

Audited 4 September 2026 · re-verified 5 September 2026 · this is the working document behind the teardown

The teardown argues a case. This page is the evidence it rests on, published in full so you can disagree with it specifically rather than generally. Every row traces to a file and a line, and §8 has the commands to re-run the whole thing.

1. How to read the grades

Every claim carries an evidence grade, and they are not decoration — the difference between grade A and grade B below is the difference between a finding and a hypothesis.

2. Group A — provenance: you cannot say what you shipped

The inventory below was assembled by hand for this audit. It is the missing SBOM, and it took twenty minutes — which is the point.

The third-party surface is unusually small: no CMSIS, no ST HAL, direct register access in src/hal.c. That is a genuine strength and worth saying out loud — an SBOM here is a morning's work, not a quarter's.

3. Group B — the CVEs that provenance was hiding

Mongoose 7.20 is the version on disk; 7.23 is current. Every identifier below was confirmed against OSV (api.osv.dev/v1/vulns/<CVE-ID>), not against a search summary.

Applicability was decided by two artefacts, not by the version string: the symbol table of the built ELF, and the linker map. Anything listed in the Discarded input sections region of build/firmware.map was garbage-collected and is not in the binary.

B1 — Applies to this build (2)

On severity. OSV publishes a CVSS vector for each of these and no numeric score; all three are VulDB-assigned. The vectors are CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:P for CVE-2026-6985, and the same with AC:H for the other two (VA:L for CVE-2026-2967, VI:L for CVE-2026-2966). An earlier draft of this page printed “4.0” in a column headed CVSS v4. That was the specification version read as a rating, and it is corrected here rather than quietly deleted.

One grade-B mapping. CVE-2026-2966's advisory names mg_sendnsreq, which does not appear under that name anywhere in the amalgamated build. The resolver path is unambiguously present, but the symbol-to-advisory mapping is grade B, unlike the other two, which are A. Saying “the resolver path is in the binary” is defensible; saying “mg_sendnsreq is in the binary” is not.

Correction, 6 September 2026. An earlier version of this page counted CVE-2026-2966 in B1 on the strength of that linkage. That was one rung too shallow and it has moved to B3. Linked in is not the same as reached: mg_resolve() short-circuits to mg_connect_resolved() whenever the host parses as a literal address (mongoose.c:397–404), the resolver's only possible caller is the MQTT client, and its configuration field is named broker_ip (src/mqtt_cl.c:171). What decides it is not the build but the configured value — and the field is a char[48] (src/mqtt_cl.h:13) validated only for non-emptiness (src/mqtt_cl.c:184), while the firmware's own IP parser (parse_ip4, src/main.c:29) is applied to the static network config at :54–56 and never to this field. My own documentation describes it as “MQTT broker IP or hostname” (docs/DCSwitch2_Firmware.md:249) while the worked example at :192 is an address literal. The name says one thing, the documentation says another, the code enforces neither. That is finding A2 in a different costume, and it is the reason the ladder has four rungs and not three: version → build configuration → reachability → deployment, each level getting the one above it wrong.

The fix note: “upgrade to 7.23” does not close all three

An earlier draft said 7.21 fixes all three. It does not, and finding that out required reading the upstream source, because OSV alone answers it wrongly in both directions.

The 7.23 resolver still calls mg_random(&id, sizeof(uint16_t)) and then overwrites it whenever a request is already in flight. 7.20 replaced sixteen random bits with a deterministic previous + 1; 7.23 replaces them with previous + rand8 + 1. That is eight bits of entropy instead of zero, not the sixteen the random call was meant to supply — and the upstream comment now reads “no seq, no collision for upto 256 in-flight requests”, which tells you the change was made for collision avoidance. The spoofing resistance is a side effect.

Two things follow, and together they are the whole argument for reading source instead of trusting a version number:

1. last_affected: 7.20 is not a fix record. It is a CPE range that ends where the release train happened to be on the disclosure date. Two of these three read identically in OSV and have opposite answers in the source.
2. Upgrading 7.20 → 7.23 closes two of the three and mitigates the third. That is still the right move — but “we upgraded, we are clear” would be a false statement, and a manufacturer who repeats it in an Article 14 context has been misled by their own tooling.

B2 — Does not apply: removed by the compiler or the linker (12)

An earlier pass recorded handle_mdns_record as merely “not observed in the symbol table,” hedged because a static function may be inlined. The linker map settles it: the section was discarded. Absence is grade A here, not a hint.

B3 — Depends on deployment, not on the build (3)

CVE-2026-73256 and CVE-2026-73257 — HTTP request smuggling (a CL.TE desync and an HTTP/1.0 detection off-by-one), fixed in 7.22. The HTTP parser is linked in (mg_http_parse 0800ccc4), but both advisories need a reverse proxy in front of Mongoose to desynchronise against. Standalone on a LAN: not exploitable. Behind an HTTP/1.0 proxy: exploitable. The build cannot answer this one — only the deployment can, which is why an SBOM that stops at the component list stops one step short of the answer.

CVE-2026-2966 — weak DNS transaction IDs, not fixed in any released version (see the fix note above). The resolver is linked in, and fires only if the MQTT broker is configured by hostname rather than by address; configured by address, no query is ever sent. Moved here from B1 on 6 September — the reasoning and the citations are in §3 above. The build cannot answer this one either — the config value can.

B4 — The finding underneath the findings

4. Group C — process: no way to hear, no way to tell

5. Group D — what reading the code found

These are not paperwork. A questionnaire would have missed all three, because the firmware has authentication, has access control and has a documented update path.

6. The pass

7. The count

Eleven findings, one pass, one afternoon. Five are provenance, three are process, three are engineering defects found by reading code. On the CVEs: two apply to this build unconditionally, three depend on how it is deployed, and twelve are not in the binary — seventeen in total. The provenance and process gaps are what make Article 14 unanswerable. The engineering defects are what a compliance questionnaire would have scored as compliant.

8. Re-run it yourself

Point these at your own tree. The interesting one is the second block — it is the difference between “our SBOM lists a vulnerable version” and “the vulnerable code is in our binary.”

cat -n scripts/get_mongoose.sh                  # A1
git status                                      # A2
grep -n '__DATE__' src/main.c                   # A3
find . -iname '*sbom*' -o -iname '*.spdx*' \
       -o -iname '*.yml' -o -iname 'SECURITY*' \
       -o -iname 'security.txt' | grep -v ./build   # A4, A5, C1
grep -n 'broker_ip' src/mqtt_cl.c src/mqtt_cl.h  # B3: what decides CVE-2026-2966
grep -n 'MG_VERSION' mongoose.h                 # inventory
grep -n 'SPDX' mongoose.h                       # licence

Is a function in the binary, or did the linker discard it? Do not hardcode the boundary — it moves on every rebuild, which is the lesson from the note in §3.

BOUND=$(grep -n '^Memory Configuration' build/firmware.map | head -1 | cut -d: -f1)
echo "discarded-section boundary: line $BOUND"
for s in handle_opt getpeer handle_mdns_record mg_http_serve_ssi \
         mg_http_next_multipart mg_http_serve_dir mg_tls_init \
         mg_aes_gcm_decrypt mg_tls_verify_cert_signature mg_http_parse; do
  ln=$(grep -n "\.text\.$s\b" build/firmware.map | head -1 | cut -d: -f1)
  [ -z "$ln" ] && echo "$s: ABSENT FROM MAP" && continue
  [ "$ln" -lt "$BOUND" ] && echo "$s: DISCARDED ($ln)" || echo "$s: LINKED IN ($ln)"
done

And check the fix status against OSV — then check the source anyway, because §3 is what happens when you do not.

for id in CVE-2026-6985 CVE-2026-2967 CVE-2026-2966; do
  echo "== $id"
  curl -s "https://api.osv.dev/v1/vulns/$id" | python3 -c "
import json,sys; d=json.load(sys.stdin)
ev=[e for a in d.get('affected',[]) for r in a.get('ranges',[])
      for e in r.get('events',[])+r.get('database_specific',{}).get('extracted_events',[])]
print(' fixed:', [e['fixed'] for e in ev if 'fixed' in e] or 'NONE RECORDED')"
done

9. Open items — what I have not verified

Listed because an audit that does not say where it stops is not an audit.

1. The penalty tier. Article 64's top tier is reported to cover Article 13 and 14 breaches. That is grade B — law-firm commentary, not read from the article — which is why no penalty figure appears anywhere on this site.
2. Article 33. Micro and small enterprises may use a simplified Annex VII technical-documentation format, to be specified by Commission implementing act (grade B). There is no reporting exemption. Anyone telling you otherwise has read a summary.
3. security.txt is good practice, not a CRA requirement. Annex I Part II asks for a coordinated vulnerability disclosure policy; security.txt is one cheap way to publish the contact point. Do not conflate the two.
4. The French reporting route. CERT-FR (ANSSI) is the designated CSIRT coordinator and notifications route through the ENISA Single Reporting Platform — grade B, from ANSSI and gouv.fr pages rather than from the implementing act.

And the caveat that should not need saying: none of this is legal advice, and reading it does not make anyone CRA-compliant. It is one engineer's audit of one firmware, published because the failures are more useful than the successes.