2 CVEs: Kan & Arcane (CVE-2026-32255)

Two self-hosted web applications were added to VulnCheck’s KEV catalog on the same day, September 17, 2026, with the same defect implemented independently: an HTTP endpoint that takes a URL from the caller, fetches it from the server, and hands back the response body — with no authentication and no validation of where the URL points. Both are CWE-918. Both CVEs were published in the spring, with a fixed release already named in the record, and reached the catalog in September.

Neither CVE is on CISA’s Known Exploited Vulnerabilities catalog as of our most recent CISA KEV ingestion on September 19, 2026. Both exploitation reports come from VulnCheck alone, so no Binding Operational Directive 26-04 obligation attaches to either, and both records are rated medium confidence here rather than high.

CVE-2026-32255 — Kan, versions 0.5.4 and below

Kan is an open-source project management tool. Per NVD, its attachment-download endpoint — spelled /api/download/attatchment in the affected code, typo included — carries neither authentication nor URL validation. It takes a URL from a query parameter, passes it to a server-side fetch, and returns the full response body to the caller.

NVD’s own description names the consequences: requests reaching internal services, cloud metadata endpoints, and private network resources. The C:H in the vector is doing the work there — this is scored as a full confidentiality compromise, not a partial one, because the response body comes back rather than being discarded.

Fixed in 0.5.5. The advisory also documents a workaround for operators who cannot update immediately: block or restrict the endpoint at the reverse proxy.

CVE-2026-40242 — Arcane, before 1.17.3

Arcane is a management interface for Docker containers, images, networks, and volumes. Per NVD, its template-fetch endpoint accepts a caller-supplied url parameter and performs a server-side GET against it with no authentication and no scheme or host validation, returning the response to the caller. NVD notes the issue affects any publicly reachable instance. Fixed in 1.17.3.

The score is 7.2 against Kan’s 8.6, the difference sitting in C:L/I:L versus C:H/I:N. We would not read that gap as a ranking of real-world risk, for a reason the score is not built to capture: what a request originating from this particular host can reach. A Docker management interface lives, by construction, adjacent to container orchestration and the internal networks those containers sit on. A fetch primitive on that host starts from a better position than the same primitive elsewhere. CVSS scores the flaw, not the placement — which is the usual reason a base score and an operator’s own prioritisation should not be expected to agree.

Returning the body is what makes these severe

Server-side request forgery covers a wide quality range. At the low end, a blind variant confirms only that something responded, and turning that into intelligence takes inference and repetition. At the high end, the application returns the response, and the flaw stops being a probe and becomes a read primitive against everything the server can reach.

Both of these are at the high end, and both advisories say so explicitly. That single design choice — returning the body for operator convenience — is what moves the impact from reconnaissance to disclosure, and it is why the mitigation for the unpatched case is reachability rather than filtering. A denylist of internal address ranges is a well-known losing position against redirects and alternative address encodings; removing the caller’s access to the endpoint is not.

Quietlytic covered the redirect-based variant of exactly that losing position in Smarty’s trusted-URI policy bypass, where an open redirect on an allowed host was enough to defeat the allowlist, and the appliance case in SonicWall’s SMA1000 advisory, where a pre-auth SSRF was KEV-listed alongside a post-auth command injection in the same product.

The EPSS split is worth not over-reading

Kan sits at 0.208, the 97.4th percentile. Arcane sits at 0.006, the 48.1st. Two CVEs with the same weakness class, the same access requirements, the same catalog, and the same listing date are separated by a factor of roughly thirty-three in modelled exploitation probability.

EPSS is a prediction trained on observable signals — public exploit artifacts, references, product prevalence — and it is not a measure of whether a given CVE has been exploited. Both of these are already flagged as exploited by VulnCheck, which is a claim about the past that EPSS’s forecast does not override. Read the split as a statement about how much public signal each CVE has accumulated, and not as a reason to defer the Arcane update.

What we don’t have

• No CISA KEV listing for either CVE as reflected in our ingestion through September 19, 2026.
• No structured affected-version ranges. “0.5.4 and below” and “prior to 1.17.3” are description prose in our records, not machine-readable ranges.
• Single-source CVSS. Both scores come from NVD alone, with no second score and no recorded conflict.
• Single-source exploitation. VulnCheck is the only source in our data reporting either CVE as exploited, and we have no detail on what was observed, against which versions, or when.
• No linkage evidence between the two. They arrived in the same catalog on the same day with the same defect class. Nothing in our data indicates a common campaign, a common reporter, or any relationship beyond that coincidence, and we are not implying one.

Frequently Asked Questions

What do CVE-2026-32255 and CVE-2026-40242 have in common? Both are unauthenticated server-side request forgery flaws, CWE-918, in self-hosted web applications. Each exposes an endpoint that fetches a caller-supplied URL from the server and returns the response body, with no authentication and no validation of the target. Both were added to VulnCheck’s KEV catalog on September 17, 2026.

Which versions fix them? Kan 0.5.5 fixes CVE-2026-32255; Arcane 1.17.3 fixes CVE-2026-40242.

Are these CVEs on the CISA KEV catalog? Neither is, as reflected in our CISA KEV ingestion through September 19, 2026. The exploitation reports come from VulnCheck’s catalog, which is broader in scope and does not carry BOD 26-04 obligations.

Why does Kan score higher than Arcane? NVD assigns Kan C:H (high confidentiality impact) against Arcane’s C:L/I:L. Both carry scope-changed, network-reachable, no-privilege vectors. The gap reflects the assessed impact of each flaw in isolation, not the value of what an attacker could reach from each host.

What should operators do if they cannot update immediately? Restrict reachability of the affected endpoints — the Kan advisory specifically documents blocking its attachment-download path at the reverse proxy. Address-range denylisting is a weaker control against this class of flaw than removing caller access outright.

Data sourced from the National Vulnerability Database (NVD), VulnCheck KEV, and FIRST EPSS, aggregated September 19, 2026. Upstream fixes: Kan 0.5.5, Arcane 1.17.3. See more vulnerability intelligence.