critical CVSS 9.8 EPSS 0.39%

CVE-2024-47832·Docker vulnerability

ssoready is a single sign on provider implemented via docker. Affected versions are vulnerable to XML signature bypass attacks. An attacker can carry out signature bypass if you have access to certain IDP-signed messages. The underlying mechanism exploits differential behavior between XML parsers. Users of https://ssoready.com, the public hosted instance of SSOReady, are unaffected. We advise folks who self-host SSOReady to upgrade to 7f92a06 or later. Do so by updating your SSOReady Docker images from sha-... to sha-7f92a06. There are no known workarounds for this vulnerability.

Severity
critical
Software
Docker
Fixed in
2024-10-09
Published

How likely is exploitation

FIRST's Exploit Prediction Scoring System puts the probability of this CVE being exploited in the next 30 days at 0.39% — higher than 31% of all published CVEs. EPSS is an independent forecast of exploitation, not a severity rating: it says nothing about how much damage a successful attack does, which is what a CVSS score measures.

Read the two together. CVE-2024-47832 scores 9.8 on CVSS, so a successful attack would be serious — but at 0.39%, almost nobody is currently attempting it. That is a different situation from a flaw under mass exploitation, and it is usually the difference between patching on your next maintenance window and patching tonight.

Affected versions

Until: 2024-10-09

Fixed in: 2024-10-09

How to fix this CVE

Self-hosted SSOReady deployments must update their Docker images to commit 7f92a06 or later to patch a critical XML signature validation flaw that could allow unauthorized authentication bypass. Update your running Docker container images immediately by pulling the latest SSOReady release and redeploying. Cloud-hosted users on ssoready.com are not affected by this vulnerability.

sudo dnf update docker-ce

Defensia detects this vulnerability

How to check if you are affected

  1. Step 1: Run `docker --version` to confirm Docker is installed and note the current version
  2. Step 2: Run `docker images | grep ssoready` to list all SSOReady container images and their current SHA digests
  3. Step 3: Compare the running image SHA against the fixed commit 7f92a06 by inspecting the image details with `docker inspect <image_id> | grep -i digest`
  4. Step 4: After updating, re-run `docker images` and verify the SSOReady image SHA has been updated to reflect the patched commit

FAQ

What is CVE-2024-47832?

CVE-2024-47832 is a critical XML signature bypass vulnerability in self-hosted SSOReady instances that allows attackers to forge authentication tokens by exploiting inconsistencies between XML parser implementations. This could enable unauthorized access to protected resources without valid credentials.

Is CVE-2024-47832 being actively exploited?

No, there are currently no known active exploits or public proof-of-concept code for this vulnerability according to CISA and public security databases.

What versions of Docker are affected by CVE-2024-47832?

This vulnerability affects self-hosted SSOReady instances running Docker images created before October 9, 2024. All versions prior to commit 7f92a06 are vulnerable; the vulnerability was fixed on 2024-10-09.

How do I check if my server is vulnerable to CVE-2024-47832?

Run `docker inspect <ssoready_image> --format='{{.RepoDigests}}'` and verify the digest corresponds to commit 7f92a06 or later. If your image is older than October 9, 2024, you are vulnerable.

Does Defensia detect CVE-2024-47832?

Yes — Defensia's CVE advisory scanner compares installed package versions against the NVD database. If Docker is installed on a monitored server, CVE-2024-47832 will appear in your dashboard with remediation steps.

Related Docker CVEs

CVE-2026-33587CVSS 10Lack of user input sanitisation in Open Notebook v1.8.3 allows the application user to execute Python code (and subsequently OS commands) on the docker container via Server-Side Template Injection (SSTI) for user-created transformations.
CVE-2026-26216CVSS 10Crawl4AI versions prior to 0.8.0 contain a remote code execution vulnerability in the Docker API deployment. The /crawl endpoint accepts a hooks parameter containing Python code that is executed using exec(). The __import__ builtin was included in the allowed builtins, allowing unauthenticated remote attackers to import arbitrary modules and execute system commands. Successful exploitation allows full server compromise, including arbitrary command execution, file read and write access, sensitive data exfiltration, and lateral movement within internal networks.
CVE-2026-44329CVSS 10free5GC is an open-source implementation of the 5G core network. Prior to 4.2.2, free5GC's SMF mounts the UPI management route group without OAuth2/bearer-token authorization middleware. A network attacker who can reach SMF on the SBI can hit UPI endpoints with no Authorization header at all, and the requests reach the SMF business handlers. In the running Docker lab this was directly demonstrated for read (GET /upi/v1/upNodesLinks), write (POST /upi/v1/upNodesLinks with attacker-controlled UP-node and link payload), and delete (DELETE /upi/v1/upNodesLinks/{nodeID}) operations. This vulnerability is fixed in 4.2.2.
CVE-2026-44181CVSS 10Jupyter Enterprise Gateway launches remote Jupyter Notebook kernels across distributed clusters like Apache Spark, Kubernetes, and Docker Swarm. In versions 2.0.0rc2 and above, prior to 3.3.0, the environment variables (KERNEL_XXX) used during the rendering of the Kubernetes manifest are vulnerable to Server Side Template Injection (SSTI). By including Jinja2 template expressions it is possible to execution Python code and OS Commands in the Enterprise Gateway service. The code can use or steal the Kubernetes service account token, which can steal Kubernetes secrets and be used to fully compromise the Kubernetes cluster by scheduling a privileged pod or a pod with a hostPath volume mount. This issue has been fixed in version 3.3.0.
CVE-2026-40281CVSS 10Gotenberg is a Docker-powered stateless API for PDF files. In versions 8.30.1 and earlier, the metadata write endpoint validates metadata keys for control characters but leaves metadata values unsanitized. A newline character in a metadata value splits the ExifTool stdin line into two separate arguments, allowing injection of arbitrary ExifTool pseudo-tags such as -FileName, -Directory, -SymLink, and -HardLink. This is a bypass of the incomplete key-sanitization fix introduced in v8.30.1. An unauthenticated attacker can rename or move any PDF being processed to an arbitrary path in the container filesystem, overwrite arbitrary files, or create symlinks and hard links at arbitrary paths.

References

Track CVEs across your fleet automatically

Defensia scans your Linux servers and tells you exactly which ones are running vulnerable versions — including CVE-2024-47832. Free for 1 server.

Get started free