CVE-2026-61741 is an XML External Entity vulnerability affecting certain http4s-scala-xml decoders. Applications are potentially exposed when an affected version uses the vulnerable EntityDecoder[F, scala.xml.Elem] path to parse attacker-controlled or otherwise untrusted XML. Successful exploitation can expose local files readable by the service process, trigger server-side requests to reachable internal resources or cause denial of service.
Direct answer: Check whether your application uses http4s-scala-xml before 0.24.1, or the 1.0 milestone line before 1.0.0-M39. If it does, determine whether untrusted XML can reach the affected scala.xml.Elem decoder and upgrade to 0.24.1, 1.0.0-M39 or a later fixed release on the applicable version line. The reviewed evidence does not confirm active exploitation.
CVE-2026-61741 affected and fixed versions
| Release line | Affected | Fixed |
|---|---|---|
| 0.x line | Versions before 0.24.1 | 0.24.1 or later |
| 1.0 milestone line | 1.0.0-M1 through versions before 1.0.0-M39 | 1.0.0-M39 or later |
The version check is only the first part of exposure verification. A vulnerable dependency does not automatically prove that an application presents a remotely reachable vulnerable path.
When is an http4s application exposed?
The reviewed advisory describes the issue in XML entity decoding through an affected EntityDecoder[F, scala.xml.Elem] path. The security-relevant condition is that attacker-controlled or otherwise untrusted XML reaches that decoder while the application is running a vulnerable release.
That distinction matters. A service that includes an affected dependency but never sends untrusted XML through the vulnerable decoder does not have the same exposure state as an internet-facing endpoint that accepts XML supplied by arbitrary clients.
What can the XXE flaw do?
XML External Entity processing can cause the server-side XML parser to resolve external resources that should not be available to attacker-controlled input.
For CVE-2026-61741, the reviewed advisory supports three primary impact classes:
- Local-file disclosure: crafted XML can expose files that the service process itself has permission to read.
- Server-side request forgery: the parser can be induced to make requests toward resources reachable from the server’s network context, including potentially internal services.
- Denial of service: malicious entity expansion can consume resources and disrupt availability.
The advisory does not establish arbitrary code execution. It also does not mean the affected service can read files beyond its operating-system permissions or reach internal resources that are not accessible from its runtime environment.
Is CVE-2026-61741 actively exploited?
TPS found no confirmed active exploitation in the reviewed evidence used for this article. The vulnerability’s severity and potential impact should therefore be kept separate from exploitation status.
A critical CVSS rating describes technical severity under the scoring model; it is not evidence that attackers are currently exploiting the flaw in real deployments.
How to check your exposure
- Confirm the dependency. Determine whether the deployed application actually includes
http4s-scala-xml. - Check the resolved version. Identify the version present in the deployed build rather than relying only on a source manifest that may resolve differently through dependency management.
- Identify XML decoding paths. Check whether the application uses the affected
EntityDecoder[F, scala.xml.Elem]functionality. - Determine whether input is untrusted. Establish whether external users, integrations or other untrusted sources can submit XML that reaches that decoder.
- Upgrade the affected release. Move to 0.24.1, 1.0.0-M39 or a later fixed release on the applicable line.
- Verify the deployed result. Confirm that the production artifact actually resolves to the fixed version after deployment.
What should teams review after upgrading?
If the vulnerable XML path was reachable by untrusted input before the upgrade, teams can assess what the service process was capable of accessing. Relevant questions include whether the service account could read sensitive local files and whether the runtime network could reach sensitive internal endpoints.
This is an exposure assessment, not evidence that exploitation occurred. Do not classify a system as compromised solely because a vulnerable version was deployed.
What proves remediation?
The software-side remediation state is established when the deployed application is using a fixed release—0.24.1, 1.0.0-M39 or a later fixed release on the applicable version line—and the previously vulnerable parser implementation is no longer running in the affected form.
Where the vulnerable route had meaningful external exposure, vulnerability remediation and compromise assessment are separate tasks. Upgrading closes the known software condition; it does not retrospectively prove that no malicious requests were received before the fix.
What happens next?
TPS will watch the GitHub/http4s advisory for revised affected or fixed version ranges, additional mitigation guidance, confirmed exploitation, CISA Known Exploited Vulnerabilities status, public exploit developments that materially change defensive urgency and downstream product advisories.
Verification note: TPS reviewed the GitHub advisory record and corroborating OSV and GitLab Advisory Database entries for the affected parser behavior, version ranges, fixed releases and published impact. Active exploitation was not confirmed in the reviewed evidence.