CVE-2026-115905

Details and PoC exploit code are out for CVE-2026-115905, a critical 10.0 CVSS Rust zip crate vulnerability. Upgrade to version 9.0.5 immediately. #Rust #ZipCrate #CVE2026115905 #PoC #RCE #Cybersecurity #Vulnerability #InfoSec https://meterpreter.org/rust-zip-crate-vulnerability-poc-disclosed/

zip crate にクリティカルな脆弱性が報告されてる（CVE-2026-115905）．9.0.5 未満は要アップデート https://cvefeed.io/vuln/detail/CVE-2026-115905

🔥 CyberForge CVE of the Day #088 🚨 CVE-2026-115905 — Rust zip: ZIP cloaking can bypass an inspection decision and overwrite files An inspection decision can fail when the next parser acts on a different view of the same archive. Here, a ZIP's central directory and local file headers can tell different stories. Rust zip's ZipArchive uses central-directory metadata; ZipStreamReader processes local headers. Crafted archives can pass one component's filename inspection and produce a different file during streaming extraction. ⚠️ Prioritise untrusted ZIP ingestion where scanning and extraction use different reader paths. The 9.0.5 correction adds consistency checks, but the streaming constructor leaves them off by default. 🎯 The quick hit What is happening? A ZIP entry has metadata near its content and another record in the central directory. If those descriptions disagree, a scanner and a streaming extractor can identify different names or entries. The advisory describes security-control bypass and file overwrite, with possible downstream code execution or service disruption. Who needs to check? Untrusted ZIP gateways, upload/import/build jobs and workers using the Rust zip crate from zip-rs/zip2. CNA lists versions below 9.0.5. Inventory embedded dependencies and actual reader calls. Why does it matter here? The first reader's clean filename list may differ from extraction output. Even a destination-relative name can overwrite a writable trusted file. Preserve ZIP, decision, job and write evidence. Start with: Verify running build, scanner/extractor paths, enabled consistency checks and error handling. Isolate staging; allow output promotion or consumption only after complete validation and policy success. Follow this trail: ZIP digest → submission/job → inspection decision → extraction worker → written file → any later consumer or execution. Preserve identifiers, process identity and timestamps across the stages. Escalate when: A job links to unexpected overwrite, consumption after validation failure or corroborated unauthorised execution. Dependency/mismatch findings alone do not prove compromise. Be careful with: Upgrade presence, validation enabled, validation completed and output safely released are separate acceptance questions. An extraction error can arrive after writes have occurred. 🔑 Key details: ⭐ Severity: Critical — GitHub CNA / zip-rs advisory. 📊 CVSS v4.0: 10.0. 🧮 CNA base vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:L NVD is Awaiting Analysis, with GitHub's Secondary metric from security-advisories@github.com. Its optional X metrics mean not defined, not a separate NIST assessment or exploitation finding. No valid CVSS v3.1 assessment was available in the reviewed CNA/NVD records. The advisory's demonstration text mixes “10.0 / 9.9” labels; this edition retains the structured published v4.0 score and exact base vector. 🧠 Weaknesses: CWE-20, Improper Input Validation; CWE-436, Interpretation Conflict. 🎯 Identity: Rust crate zip; repository/product zip-rs/zip2; affected API path includes ZipStreamReader. This does not identify every operating system's ZIP utility as affected. 🔓 Access: Network, Low complexity, no attack requirements, privileges or user interaction per vector. Applicability still needs attacker-controlled archives reaching the relevant stages. No universal upload endpoint is specified. ⚔️ Impact: Inspection bypass and file overwrite. Later execution depends on written content, worker permissions and a consumer. Root/SYSTEM, container-to-host escape and credential theft are not automatic. 🛡️ Correction: Advisory/CNA name 9.0.5. Tagged source confirms added validation APIs, including an opt-in streaming setting. Verify the corrected build, the enabled control and handling of partial output. 📋 CISA KEV: No exact match in direct and official mirror catalogue 2026.10.26, with 1,758 entries, checked at cutoff. A dated non-match does not establish safety. 📈 FIRST EPSS: Unavailable: the successful API response returned total 0 and data []. No probability, percentile or score date was supplied; this is not a 0% forecast. 🚫 Exploitation / PoC: A public demonstration appears in the vendor advisory and was reviewed as text. No active exploitation was established in the bounded reviewed primary evidence. No reproduction, extraction or payload execution was performed here. 🧬 What went wrong? A random-access reader can consult the central directory; a streaming reader encounters local records in order. Both exist in ZIP, so a decision from one description cannot automatically approve actions based on the other. The advisory identifies that disagreement between ZipArchive and ZipStreamReader. Filename/content policy and extraction need a shared, validated interpretation before inspection becomes authority for a write. The public demonstration exercises the readers and asserts changed file content. Those assertions support overwrite. Script text or a “root” marker does not prove shell execution, a callback or privilege crossing; establish those later effects separately. The same discipline applies to real cases: archive received → inspection passed → extraction invoked → file written → trusted consumer accessed it → execution or other effect verified. Keep each step tied to its own evidence. 🛠️ Why the fix needs application verification The cited correction commit adds header-consistency validation. In tagged 9.0.5, ZipStreamReader::new sets enforce_header_consistency to false for backward compatibility. The builder method can enable it. ZipArchive also exposes validate_header_consistency for explicit validation. These are application integration controls. Installing a version that contains them does not prove that existing call sites enable or invoke them. Check the path actually serving untrusted archives, including custom visitors and wrappers. The streaming flow invokes the file visitor before finishing the later central-directory comparisons. Its extraction method creates files during that visit. A mismatch or another error can therefore be reported after a write. There is also a source/documentation conflict worth preserving: the consistency method's description promises rollback, while extract's documentation explicitly says extraction is not atomic and files may remain after an error. Static source review shows the write-before-final-check order and error propagation without an extraction rollback routine. Treat automatic rollback as unverified. Keep output isolated until complete validation and policy success. Failed jobs must not release staging, trigger watchers or feed consumers. Use the application's supported promotion/cleanup design; no generic transaction is supplied. 📦 Versions and scope Affected: CNA below 9.0.5; repository advisory through 9.0.4. Correction release: 9.0.5, published 17th October 2026. The cited code change is dated 16th October. The CVE was published on 26th October; disclosure and release are different events. Build evidence: Join resolved zip version/source to deployed executable/image digest. Include old workers, queued jobs, replicas and alternate extractors. Configuration: Record inspection/extraction readers, consistency enforcement and success/failure control of output release. A standalone ZIP tool's version does not identify an embedded library. Distribution evidence: Debian's tracker at cutoff still marked rust-zip bookworm 0.6.3-3, trixie 2.5.0-1 and forky/sid 5.1.1+dfsg-1 vulnerable, with unstable unfixed. Obtain exact distributor revision/backport status rather than assuming the upstream release corrected every packaged application. RustSec's retrieved zip listing covers separate symlink/Unix-permission issues; no exact-CVE entry was verified there. Keep those mechanisms separate. 🧭 SOC investigation trail These six checks are CyberForge investigation guidance, not a vendor-certified detector. The input, job, logging and filesystem schemas depend on the embedding application. Define a bounded UTC period, validate clock differences, and record permissions, retention and collection gaps. C01 — Identify the two readers and the running build Action / location: Obtain deployed dependency/build evidence, inspection/extraction call paths, options and output locations from application/gateway owners. Map the untrusted ZIP route. Signal / correlation: Join crate version, running image/executable digest, worker and owner. Confirm reader disagreement on affected builds; for 9.0.5+, verify enabled consistency checks and failure handling. Benign causes / limits: A lockfile may describe a retired/test build. Text searches can miss wrappers, generated code or separate services. Missing call-path evidence stays unresolved. Escalate: Prioritise confirmed vulnerable or unenforced untrusted ingestion. Incident triage separately needs suspicious file/consumer evidence. C02 — Preserve the archive and processing decisions Action / location: Preserve original ZIP bytes, digest/object key, submission/job IDs, scan decision, reader/build identity, extraction result and worker context through approved collection. Signal / correlation: Follow the same byte object across gateway, queue and worker. Distinguish digests of uploaded ZIPs, transport wrappers, transformed archives and extracted files. Benign causes / limits: Recompression, retries and deduplication can change objects or repeat jobs. A clean filename list covers that reader's view. Preserve originals without extracting them for a preview. Escalate: Unexplained differences between approved input, worker input and output manifest deserve review, especially with overwrites or validation failure. C03 — Review consistency failures and partial output Action / location: Join validation/extraction/job-state records to staging and file-write evidence using the application's actual fields. No universal event ID is published. Signal / correlation: Link failures to ZIP digest, job, worker and files written before completion. Determine whether an error still allowed downstream consumption. Benign causes / limits: Corrupt archives or unsupported features also fail. A mismatch does not prove malicious intent. Error does not mean no writes; no error does not prove validation was enabled. Escalate: Failed jobs releasing output or overwriting trusted content need urgent review. Preserve staged and prior trusted state where feasible. C04 — Establish the write and later consumer Action / location: Review retained filesystem audit, EDR, import and process records. Identify destination, prior/new file identity and worker/consumer identities. Signal / correlation: Link ZIP/job → worker/process → write/overwrite → later read/load/invocation. Compare with the approved manifest and expected workflow. Benign causes / limits: Legitimate imports, deployments and tasks can replace files. Filenames or script strings do not prove execution; shared timestamps are weaker than job/path/process identity. Escalate: Owner-denied writes or corroborated unauthorised execution warrant IR. State the actual effect and authority; a “root” marker is not root-access evidence. C05 — Scope permissions and supported follow-on activity Action / location: Establish worker/consumer identity, writable paths, mount scope and capabilities. Review linked process, network and application records. Signal / correlation: Identify which permission or consumer made a write consequential. Compare child processes, configuration/credential use or egress with baseline. Benign causes / limits: Normal hooks and outbound traffic need owner context. Container-local paths do not establish host access. Time proximity does not prove a callback or theft. Escalate: Corroborated unauthorised outcomes or privileged consumption need IR/service-owner review. Dependency presence alone establishes no secret exposure. C06 — Verify correction and retain the incident decision Action / location: Obtain running-build, option/call-path and output-release evidence across workers/replicas. Use separate approved service acceptance checks. Signal / correlation: Verify correction, enabled consistency checks, complete error handling and output isolation until approval. Legitimate archives must still follow the intended route. Benign causes / limits: New lockfiles can coexist with old processes; jobs may use different paths. Source review cannot prove a production setting or isolated watcher. Escalate: Assign unresolved builds, bypass paths, partial output and suspicious historical effects. Keep exposure, suspicion, corroborated compromise and insufficient telemetry separate. No findings ≠ proof of a clean system. The analyst handover Record owner/build, reader paths/options, release policy, ZIP/job IDs, time window, worker/consumer identities, writes/effects, alternatives and coverage gaps. Remediation and historical incident disposition need separate evidence. 🔎 Indicators and observable behaviour No campaign-specific IP, domain or malicious-file hash set was verified from the reviewed primary sources. Example filenames, marker strings and network text in a public test are not campaign IOCs. Useful leads are contextual: inconsistent entry views, unexpected writes, output released after a failed job and a later unauthorised consumer action. A ZIP hash supports byte identity, not a maliciousness classification. The hypotheses above require the original object, local baseline and corroboration. KEV absence, unavailable EPSS, a clean scan or no matching alert cannot clear an environment. State exactly which objects, sources and time window were reviewed and where telemetry is missing. 🧰 Practical checks for owners Dependency and call-path review: Read the collected Cargo.lock/SBOM for the actual built application, including duplicate versions and git sources. Cargo.toml requirements alone need not identify the resolved build. Join that record to a serving executable/image digest. Inspect approved source/configuration for readers and consistency APIs. Text matches locate candidates; control-flow review establishes the active path and setting. Include wrappers, generated code and separate services. Evidence identity review: On stable authorised copies, record ZIP digest, acquisition time, source and job/object identity. Keep originals, transformed archives and extracted files distinct; compare like byte objects. Hashing establishes byte identity, without validating headers or proving execution. Preserve evidence through approved collection; avoid opening or extracting untrusted inputs just for inventory. These are bounded read-only methods. Documentation and two full-report command examples received syntax-only review; no archive, extractor, exploit or production evidence query was exercised for this edition. 🩹 Remediation and verification 1⃣ — Own the route. Identify untrusted admission, inspection, extraction and consumption owners. Where necessary, restrict affected ingestion through supported controls while correction is coordinated; account for service availability and an approved administrative route. 2⃣ — Preserve evidence. Retain original ZIP/job decisions and file/consumer records where feasible. Urgent containment may take precedence; record gaps. 3⃣ — Deploy the supported correction and enable it. Use 9.0.5 or a supported corrected later release/backport. Verify the actual application build and relevant consistency APIs/options. The tagged streaming default is false, so require call-path evidence rather than a version-only sign-off. 4⃣ — Gate output release. Isolate extraction from live files. Require complete validation/policy success before promotion or consumption. Review partial writes through supported procedures; automatic rollback is not assured. 5⃣ — Check acceptance. In an approved nonproduction fixture, verify allowed archives, rejected inconsistencies, errors, partial-output isolation and consumer boundaries. This plan was not executed here. 6⃣ — Resolve supported incident outcomes. If unauthorised writes or execution are corroborated, scope containment, restoration, secret/session action and recovery to the actual permissions and effects. A library update does not prove earlier overwritten content is restored. Interim restrictions, staging and least authority are Forge guidance, requiring integration-specific review. Assign remaining risk to a named owner. 🧾 Evidence separation Vendor / CNA: Parser differential, affected versions, correction release, CVSS v4.0 10.0 and both CWEs. Tagged source / docs: Added consistency APIs, streaming default false, file visits before final comparison and non-atomic extraction. The rollback wording conflict is retained. Public demonstration: Available in the advisory and reviewed statically. File-content assertions do not independently establish later payload execution or root authority. No local reproduction was run. CyberForge analysis: Follow archive-to-file-to-consumer evidence, isolate staging, gate promotion and verify effective options. These are proposed operational controls and investigation hypotheses. Unknown: Active campaign, local exposure, actual affected files/permissions, validated detection coverage and real remediation outcomes. EPSS is unavailable; no SSVC assessment was verified in the reviewed CVE/NVD record. 🔥 CyberForge verdict CVE-2026-115905 deserves attention because an inspection verdict can lose its meaning when the next parser acts on a different view of the archive. Priority: Untrusted ZIP workflows that split inspection from streaming extraction, especially where workers can replace files later consumed by trusted services. Verify the embedded build, enabled validation and output-release behaviour. Defender order: Map readers → preserve evidence → correct and enable checks → isolate partial output → verify consumers and supported effects. The decision that matters: End-of-stream rejection does not prove no earlier effects. Verify safe handling of both input and output. > The scanner's verdict must still be true when the worker writes the file. 🔗 Sources and further reading: Vendor advisory / public demonstration: https://github.com/zip-rs/zip2/security/advisories/GHSA-m665-v7pm-7grj CVE: https://www.cve.org/CVERecord?id=CVE-2026-115905 NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-115905 Correction commit: https://github.com/zip-rs/zip2/commit/8068ab480ccf8daa7411424e365fcdbe6d09443e 9.0.5 release: https://github.com/zip-rs/zip2/releases/tag/v9.0.5 Tagged streaming API: https://docs.rs/zip/9.0.5/zip/unstable/stream/struct.ZipStreamReader.html Tagged archive API: https://docs.rs/zip/9.0.5/zip/read/struct.ZipArchive.html CISA KEV: https://www.cisa.gov/known-exploited-vulnerabilities-catalog FIRST EPSS lookup: https://api.first.org/data/v1/epss?cve=CVE-2026-115905 Debian status: https://security-tracker.debian.org/tracker/CVE-2026-115905 Cargo records: https://doc.rust-lang.org/cargo/guide/cargo-toml-vs-cargo-lock.html #CyberSecurity #CVE #BlueTeam #SOC #CyberForge #Rust #ZIP

The Rust zip crate scores its new parser differential 10.0: a gateway reading the central directory sees one filename, the streaming extractor writes another. No exploitation reported. https://severitydaily.com/rust-zip-crate-cve-2026-115905-parser-differential-10-0-9-0-0-no-8-x-backport/