Open Source · · 11 days

Kong Ingress image shipped cryptominer

An attacker used a pull_request_target workflow weakness on an old Kong Ingress Controller branch to steal CI secrets and publish an unauthorized DockerHub image for version 3.4.0.

Kong had already received a November 2024 report about a Pwn Request path in the KIC repository. The active branches were changed, but old unused branches still had workflows triggered by pull_request_target. On December 23, an attacker opened a pull request against one of those branches and used it to reach CI secrets.

The attacker obtained a GitHub personal access token used by KIC automation. Kong later said the malicious payload was probably inserted through a transiently compromised GitHub Actions pipeline, not by direct theft of a DockerHub token. The attacker pushed an unauthorized image so the DockerHub :latest, :3.4, and :3.4.0 tags pointed to the compromised build.

Users reported high CPU usage on December 29. Kong reproduced the behavior on January 2 and found the public 3.4.0 image making DNS requests to subdomains of supportxmr.com. Third-party analysis concluded that the only malicious payload was XMRig. ARMO also described runtime behavior consistent with cryptomining, including high CPU use, communication with pool.supportxmr.com, and fileless execution through memfd_create.

Kong deleted the affected 3.4.0 tag, rebuilt from a clean environment, published 3.4.1, and moved clean images back under the 3.4 and latest tags. The advisory told users who pulled 3.4.0 between December 22, 2024 and January 3, 2025 to remove the image from clusters and internal registries and pull the remediated image.

Notes

  • A bounded ARMO report-derived runtime-indicator fragment is retained under samples/. It preserves the malicious digests and documented XMRig, pool.supportxmr.com, high-CPU and memfd_create indicators without reconstructing the image.
  • The corpus holds an uncompressed compromised manager ELF (SHA-256 0492d814e60c424463e1b0fe6458e1447240ff6aa2d1e6a9d37888c123d7ad69, 78,487,704 bytes) and a clean comparator. That digest is an extracted-member identity, not an image hash.

Appendix · Affected releases

3.4.0 sha256 0492d814…23d7ad69 too large to host
  • Kong reported that the unauthorized image was downloaded 202 times.
  • Kong's fixed 3.4.0 image hashes were sha256:b358296fa6a1458c977c0513ff918e80b708fa9d7721f9d438f3dfce24f60f4f (AMD64) and sha256:e0125aa85a4c9eef7822ba5234e90958c71e1d29474d6247adc3e7e21327e8ee (ARM64). These are clean replacements.
  • Kong reported no evidence that any other images before or after the malicious hash were affected.

References

  1. Unauthorized image of Kong Ingress Controller v.3.4.0github.com
  2. December 2024 Unauthorized Kong Ingress Controller 3.4.0 Buildkonghq.com
  3. Malicious Kong Ingress Controller Image Found on DockerHubhackread.com
  4. Tackling the recent Kong ingress controller security incident with ARMO's behavioral CADRarmosec.io
  5. Kong-ingress-controller 3.4 has high CPU usage when running 2 podsgithub.com

Source record: oss/attacks/kong-ingress-controller/meta.yaml