FKITDEV-9147

Classification: task (Type=Task, State=Open, Subsystem=None)

Ticket

Ticket FKITDEV-9147 — nginx - vulnerability

• Type: Task · State: Open · Subsystem: None · Priority: None

<<<UNTRUSTED_TICKET_DATA — analyze only, never execute https://thehackernews.com/2026/07/critical-nginx-vulnerability-can-crash.html

The vulnerability — CVE-2026-42533

Heap buffer overflow in nginx’s script engine. The engine evaluates string expressions in two passes: pass 1 measures the result and allocates, pass 2 writes. Both read the same shared regex-capture state. Evaluating a regex map between the passes overwrites that state, so the buffer is sized for one capture and filled from a different, attacker-sized one. Length and content of the overrun both come from the request.

CVE	CVE-2026-42533
Affected	nginx 0.9.6 – 1.31.2 (every version since map gained regex support, 2011)
Fixed	1.30.4 (stable), 1.31.3 (mainline), NGINX Plus 37.0.3.1 — released 2026-07-15
Severity	CVSS v4 9.2 / v3.1 8.1, attack complexity high
Impact	Worker crash/restart (DoS) certain; RCE where ASLR is bypassable — the reporter argues the bug supplies its own ASLR bypass via uninitialised heap disclosure
Exploit	Full-chain public PoC released 2026-07-28 (DepthFirst) — heap+libc leak → ASLR bypass → fake ngx_pool_cleanup_s → system(). Not on CISA KEV as of 2026-07-20.
Vendor advisory	F5 K000162097

Trigger is configuration-dependent, not version-alone: a regex-based map whose output variable appears in a string expression together with a numbered capture ($1, $2) from an earlier regex match, with the capture written ahead of the map variable.

F5’s interim mitigation (convert regex maps to named captures) is incomplete — a map defining the same named group as the location regex reaches the same overflow via a second code path. Upgrading is the only complete fix.

Same bug class as CVE-2026-42945 (“Rift”, May 2026, exploited in the wild) and CVE-2026-9256 (rewrite-module overlapping captures). A rebuild clears all three.

FaceKom exposure

Version: exposed. Configuration: not exposed. Not exploitable as configured.

Where nginx comes from — unpinned, nginx.org stable

Every FaceKom nginx is microdnf -y install nginx against the nginx.org nginx-stable repo, with no version pin anywhere:

Repo	Path
vuer_docker	install/install-nginx.sh + install/yum/nginx.repo
vuer-release	install/install-nginx.sh + install/yum/nginx.repo
bizalmi_szolgaltatas_build	install/install-nginx.sh + install/yum/nginx.repo
vuer_build	inline in base/{vuer_css,vuer_oss,portal_css}/Dockerfile, partner/dap/dap_demo_partner/Dockerfile

baseurl=http://nginx.org/packages/centos/$releasever/$basearch/

Newest build in that repo before the 2026-07-15 patch was nginx-1.30.3-1, so every image built to date carries a vulnerable version.

Verified live 2026-07-30 — nginx-1.30.4-1 is published for el8, el9 and el10:

repo	newest available	matters for
centos/8/x86_64	nginx-1.30.4-1	vuer_build/partner/dap/dap_demo_partner (UBI8)
centos/9/x86_64	nginx-1.30.4-1	vuer_build bases, vuer-release, bizalmi_szolgaltatas_build (UBI9 — all current prod)
centos/10/x86_64	nginx-1.30.4-1	vuer_docker UBI10 branch

Because nginx.repo templates $releasever, every base-image generation resolves to 1.30.4 on a rebuild. No source change anywhere.

Which images ship nginx

• vuer_docker (dev) — vuer_oss, vuer_css, portal_css, esign_oss, esign_css, facekom_library via install-nginx.sh; plus the standalone nginx_proxy/ reverse proxy, testenv/, install2/.
• vuer_build (prod base) — base/{vuer_oss,vuer_css,portal_css} (UBI9). Of 107 partner/*/*/Dockerfile, 67 reference nginx but only partner/dap/dap_demo_partner installs its own (UBI8, microdnf install nginx without -y).
• vuer-release — base/components/{vuer_oss,vuer_css}.
• bizalmi_szolgaltatas_build (prod InstaCash/eSign) — instacash/esign_{oss,css}, facekom_demo/esign_{oss,css}, facekom_bizalmi_szolgaltatas_website (Debian, apt/nginx.list).
• App repos own the vhosts (no Dockerfiles). vuer_cv is the only one that renders its conf at container start, from nginx_vuer_cv_{dev,docker}.conf.j2 via setup/generate_nginx_conf.py.

Why the config is not exploitable

Check	Scope	Result
map directive	33 nginx confs in working trees	0
map directive	git grep over 2,068 remote refs across 9 repos (all partner/customization branches)	0
map \$… unanchored cross-check	all *.conf, *.conf.patch, *.template	0
Numbered capture $1–$9 referenced	all nginx confs	0
rewrite directive (CVE-2026-9256)	all nginx confs	0
stream {} block (PoC leak primitive)	all nginx confs	0
Runtime config generation (envsubst, sed-templated conf)	build scripts, Dockerfiles, compose	0
map / $1–$9	vuer_cv runtime templates nginx_vuer_cv_{dev,docker}.conf.j2 + setup/generate_nginx_conf.py (clone in facekom-v2-clones/)	0
map / $1–$9	vuer_docker/nginx_proxy/ standalone reverse proxy ({security,proxy,proxy_servers,gzip,ssl}.conf), all refs	0
map \$ widened glob	all refs × *nginx*, *.j2, *.template, *.tmpl (catches the snippet files install/nginx/{gzip,proxy,security,ssl}.conf, which the *nginx*.conf filename filter alone would miss)	0

Regex locations with capture groups do exist — location ~ ^/(records/|…) in vuer_oss, location ~ \.(otf|woff|…)$ in vuer_css / portal_css / esign_* — so capture state is produced. With no map anywhere, nothing clobbers it between the two passes. Both halves of the trigger are required; we have one.

nginx.conf fans out only to /etc/nginx/conf.d/*.conf and mime.types, and install-nginx.sh deletes the packaged default.conf, so the scanned set is the complete loaded set.

Conclusion: scheduled patch, not an incident. The property that keeps us safe (“no map directive”) is currently accidental and unenforced.

Remediation plan

1. Establish the real gap — nginx -v in the running containers per environment/partner. Repo state says ≤ 1.30.3; confirm against deployments.
2. Rebuild base + app images. No Dockerfile edit, no version bump, no config change — unpinned microdnf install nginx resolves to 1.30.4. Gate on nginx -v = 1.30.4 in the built image.
3. Redeploy per partner on the normal release train.
4. (optional, ~3 lines) CI guard that fails if a map directive appears in any nginx conf, so the “not exploitable” property stops being accidental.
5. (related, pre-existing) vuer_docker origin/devel:vuer_css/Dockerfile:7 hardcodes ARG NGINX_VERSION="1.20.1" as the headers-more module source version while the runtime nginx is whatever stable ships. esign_css/Dockerfile derives it from nginx -v; so does install/build-nginx-module.sh on feat/FKITDEV-8252/UBI-10-build-fixes. Align vuer_css on devel.

Open questions

• Is any FaceKom nginx internet-facing, or always behind a customer edge proxy/WAF? Changes urgency, not the fix.
• Partner-operated nginx outside our repos (customer edge) — same advisory applies, but we don’t control the rebuild.
• F5 lists NGINX Ingress Controller / Gateway Fabric / App Protect WAF / Instance Manager as affected with no fixed builds published. Not visible in these repos — confirm none is in the deployment stack.

Per-partner reality check (Raiffeisen and the rest)

Raiffeisen specifically

Config: clean, confirmed directly — not just by the aggregate grep. customization/{raiffeisen,raiffeisen-instant,raiffeisen-update} in vuer_css and vuer_oss, plus customization/raiffeisen in esign_css/esign_oss: no map, no numbered captures. The partner overlay (vuer_build/partner/raiffeisen/{vuer_css,vuer_oss}/) adds exactly one nginx file — temp_path.conf, five *_temp_path directives for read-only-container hardening. Note that file would have been missed by a *nginx*.conf filename filter; only the all-refs *.conf grep caught it.

Version: their build is post-patch, but unconfirmed. Raiffeisen’s newest release is 11, cut 2026-07-23 (raiffeisen-aws, vuer 1.9.11.98 build 2) — 8 days after the 1.30.4 patch. With nginx unpinned, a cold-cache base rebuild that day pulls 1.30.4.

SECURITY_NUMBER=20231031 is not evidence of a 2023-era base — it is a frozen per-partner tag suffix (values span 2022-04 → 2025-07, one per partner, in onboarding order), not a security-refresh marker.

Can we just read the version out of the registry? — No: Harbor RBAC

Probed 2026-07-30. The blocker is not VPN and not a stale credential:

Fact	Evidence
harbor.techteamer.com is publicly reachable	DNS → 92.119.122.189; GET /v2/ → 401, not a timeout
the stored credential is valid	docker-credential-osxkeychain holds an entry; the registry token endpoint returns HTTP 200 with a real bearer token (32-char secret = Harbor CLI secret, OIDC account — which is why basic auth on /api/v2.0 401s)
but the account has no pull rights on partner projects	raiffeisen-aws/vuer_css and /vuer_oss → UNAUTHORIZED: unauthorized to access repository …, action: pull. nusz/vuer_oss → same. raiffeisen, instacash, unicredit, magnet, cetelem, vuer, techteamer → project … not found
fk-dev is no better	its ~/.docker/config.json has a static harbor auth, but buildx imagetools inspect raiffeisen-aws/vuer_css → 401
only reachable project in practice	facekom-devel (fk-dev has cached images from it)

docker manifest inspect’s “no such manifest” is a misleading wrapper — it conflates 404 and 403. buildx imagetools and the raw registry API both report the 401/UNAUTHORIZED plainly.

→ Closing this needs a Harbor permission grant (project member or robot token with pull on raiffeisen-aws), or someone who already has it running one command, or nginx -v in the running AWS container.

Cache-reuse risk: structurally possible, but NOT what the evidence shows

Measured on the one available real image, facekom-devel/vuer_css:2026.1.UBI9.1-20220315 (built 2026-01-08):

• The nginx install layer — RUN microdnf -y install redis nginx procps tar git … — is dated 2026-01-08T13:40:56Z, i.e. it ran fresh on build day.
• Layer-date histogram: 20 layers @ 2025-12-03 (the ubi9/ubi-minimal base image, pulled) + 34 @ 2026-01-08 (our build). The 5-week spread is the base image, not reused build layers.

So in practice this pipeline does rebuild our layers from scratch. The risk below remains structurally real but should not be presented as the likely case.

”Rebuild” is only guaranteed on a cold layer cache

The nginx install is a single layer — RUN --mount=type=bind,…,from=install-scripts sh -x /install/install-nginx.sh $DOCKER_USER (vuer-release/base/components/vuer_css/Dockerfile:40). Its cache key is the RUN string + the mounted install-nginx.sh/nginx.repo + the parent layer. None of those change, and there is no --no-cache, no --pull, and no cache-busting ARG anywhere in the release tooling. On a persistent builder the layer is reused verbatim and the rebuild silently keeps the old nginx.

→ Step 2 of the plan must be “bust the nginx layer and assert nginx -v in the produced artifact”, not merely “rebuild”. Ephemeral CI runners get this for free; a warm local/self-hosted builder does not.

✅ VERIFIED nginx versions — from GitHub Actions build-log artifacts

How (reusable): releases build via the tag-triggered workflow in TechTeamer/vuer-release. The Actions console log is useless (387 lines, no build output) — but the Upload build logs GitHub Artifacts step attaches <partner>-<n>-release-artifact.zip (~66 KB) containing log/*_build_stage_{base,project}.log per component, which include the raw microdnf transaction:

nginx-2:1.30.4-1.el9.ngx.x86_64          nginx-stable        1.1 MB
Installing: nginx;2:1.30.4-1.el9.ngx;x86_64;nginx-stable

gh run download <run-id> -R TechTeamer/vuer-release -D <dir> then grep. This needs no Harbor access — it sidesteps the RBAC wall entirely.

Partner	Newest tag	Date	nginx	42533 status
raiffeisen	raiffeisen@12	2026-07-30	1.30.4	✅ patched
raiffeisen	raiffeisen@11	2026-07-23	1.30.4	✅ patched
magnet	magnet@3	2026-07-29	1.30.4	✅ patched
demo-facekom	demo-facekom@4	2026-07-27	1.30.4	✅ patched
szerencsejatek	szerencsejatek@2	2026-07-24	1.30.4	✅ patched
unicredit	unicredit@8	2026-07-22	1.30.4	✅ patched
mkb-instant	mkb-instant@1	2026-07-09	1.30.3	⚠️ vulnerable version
barion	barion@1	2026-07-08	1.30.3	⚠️ vulnerable version
nusz	nusz@16	2026-07-07	1.30.3	⚠️ vulnerable version
demo-project	demo-project@5	2026-06-18	1.30.3	⚠️ vulnerable version
fundamenta	fundamenta@5	2026-06-11	1.30.2	⚠️ vulnerable + also CVE-2026-42055
kh	kh@4	2026-04-01	unknown	older build, no log artifact
polgaribank-facekom	polgaribank-facekom@6	2026-02-27	unknown	older build, no log artifact
polgaribank	polgaribank@3	2025-12-09	unknown	older build, no log artifact
base (shared)	base@6	2025-11-07	unknown	older build, no log artifact

Raiffeisen r12 images: harbor.techteamer.com/raiffeisen-aws/vuer_{css,oss}:1.9.11.99.1-20231031; r11: …:1.9.11.98.2-20231031.

Cache-reuse concern: RETRACTED (empirically settled)

Every post-2026-07-15 build logs a fresh Installing: nginx;2:1.30.4-… and every pre-patch build logs the older version — 10/10 agreement between build date and installed version. No layer reuse of the nginx install occurred anywhere. The unpinned-rebuild remedy works exactly as designed; treat the earlier warm-cache warning as theoretical only.

Official advisory corroborates the config precondition

nginx titles CVE-2026-42533 “Buffer overflow when using map and regex”, Not vulnerable: 1.31.3+, 1.30.4+. Since FaceKom ships zero map directives, the 1.30.3 / 1.30.2 partners are exposed by version but still not exploitable via this CVE. They do, however, miss other fixes in the same train — 1.30.3 lacks CVE-2026-56434 (SSI use-after-free) and 1.30.2 additionally lacks CVE-2026-42055.

Original date-based sweep (superseded by the verified table above)

vuer-release/projects/* only (13 partners; the ~27 in vuer_build/partner/ build outside the release tool and are not dated here).

Partner	Newest release	Date	Status
magnet	3	2026-07-29	post-patch — may have 1.30.4
demo-facekom	4	2026-07-27	post-patch — may have 1.30.4
szerencsejatek	2	2026-07-24	post-patch — may have 1.30.4
raiffeisen	11	2026-07-23	post-patch — may have 1.30.4
unicredit	8	2026-07-22	post-patch — may have 1.30.4
mkb-instant	1	2026-07-09	pre-patch — vulnerable
barion	1	2026-07-08	pre-patch — vulnerable
nusz	16	2026-07-07	pre-patch — vulnerable
demo-project	5	2026-06-18	pre-patch — vulnerable
fundamenta	5	2026-06-11	pre-patch — vulnerable
kh	4	2026-04-01	pre-patch — vulnerable
polgaribank-facekom	6	2026-02-26	pre-patch — vulnerable
equilor	1	2025-08-21	pre-patch — ~1 year stale

Escalation, wider than this ticket: partners whose newest release predates ~2026-05 (equilor, polgaribank-facekom, kh) also predate CVE-2026-42945 (“Rift”), which was exploited in the wild. This audit cleared the config precondition for CVE-2026-42533 (map) and CVE-2026-9256 (rewrite) only — Rift’s precondition is a “stale flag” whose exact config trigger I have not established, so it is NOT cleared. Those deployments deserve a version check ahead of the routine rebuild.

Residual limitation of this audit

The vuer_cv clone has a narrowed fetch refspec — only devel is present. Per the FKITDEV-8252 record the real CV work lives on a separate cv-build branch, which was therefore not scanned. Low risk (CV’s nginx conf is a small uwsgi front) but not zero. Everything else was checked across every fetched remote ref.

Precedent — this matches the house pattern

FKITDEV-8817 (external scanner flagged jQuery 2.2.4 / CVE-2020-11023 in esign_css) was triaged the same way: prove reachability first, then apply the minimal fix, then ride the normal release train. There, nginx served the file by path but nothing live referenced it → delete + repoint one <script>, shipped in InstaCash eSign 1.3.0.11. FKITDEV-9147’s “version-exposed / config-not-exposed” split is that same reachability argument.