Trust & Security

Date: 23 April 2026
Severity: Informational (no JuliaHub platform compromise confirmed across all incidents)
Affected Products: JuliaHub Platform

---

Overview

This bulletin covers three separate but interconnected security events that occurred during March–April 2026, all involving third-party software components used by or distributed via the JuliaHub platform. We are issuing this notice in the interest of transparency and to inform customers of the actions we have taken in each case.

---

Incident 1: Third-Party Supply Chain Attack on Trivy

Background

Trivy is an open-source vulnerability and Software Bill of Materials (SBOM) scanner developed by Aqua Security. JuliaHub uses Trivy in two capacities: as part of our static analysis service, and for container image scanning.

In early March 2026, Trivy itself became the target of a supply chain attack. The root cause was a misconfigured GitHub Actions (GHA) workflow in the Trivy project, which allowed attackers to steal repository credentials on approximately 1 March 2026. The subsequent credential rotation was not performed atomically, which may have allowed attackers continued access to refreshed tokens. This enabled a secondary supply chain compromise affecting the Trivy GitHub Action — specifically versions resolving to the v0.69.4 Docker image.

For further background on the incident:

• Attack timeline: https://ramimac.me/teampcp/
• Julia community discussion on reviewing GHA workflows and tokens: https://discourse.julialang.org/t/reviewing-github-actions-workflows-tokens/136400

JuliaHub's Exposure

We conducted an immediate audit of all Trivy usage within the JuliaHub platform and CI infrastructure:

• Static analysis service: We were running Trivy Docker image v0.69.2. Only v0.69.4 was the affected version. We were not impacted.
• Container image scanning: We source Trivy from nixpkgs, built from source, not from the affected Docker image. We were not impacted.
• GitHub Actions workflows: We identified two references to the Trivy action in our GitHub organisation. Both were pinned to a specific commit hash rather than a mutable version tag — the key practice that prevented automatic adoption of the compromised version.

Conclusion: JuliaHub was not on any affected version and was not compromised.

Preventive Actions Taken

• We completed a full audit of GHA workflow token configurations across public repositories.
• We confirmed that commit-hash pinning of third-party GHA actions is standard practice and will remain enforced.
• We increased monitoring of upstream dependency integrity for all security tooling.

---

Incident 2: LiteLLM Supply Chain Compromise

Background

LiteLLM is an open-source LLM proxy library used by JuliaHub to route and manage AI model calls within the platform. In March 2026, LiteLLM was affected by the same broader supply chain event that compromised Trivy — a malicious actor used stolen credentials (potentially connected to the Trivy GHA compromise) to inject malicious code into certain LiteLLM PyPI wheel distributions.

The LiteLLM team published an official security update disclosing the nature of the compromise:

• LiteLLM official security update: https://docs.litellm.ai/blog/security-update-march-2026
• GitHub issue tracking the compromise: https://github.com/BerriAI/litellm/issues/24512

A key factor in the wider attack was the discovery that PyPI allows new wheel (.whl) files to be retroactively added to existing version releases, meaning a package version number alone provides no integrity guarantee for Python packages.

JuliaHub's Exposure

• Our LiteLLM version: We were running v1.82.1 at the time of the compromise. The infected versions did not include v1.82.1.
• Installation method: We install LiteLLM from source, not from the PyPI wheel. The malicious payload was introduced via the wheel distribution only; source installations were unaffected.

Conclusion: JuliaHub was not running an affected version, and our source-based installation method provided an additional layer of protection against this class of attack.

Preventive Actions Taken

• We confirmed that our LiteLLM deployment installs from source rather than PyPI wheels, and this practice will be maintained.
• We confirmed that our Julia package ecosystem (JLL packages) is not susceptible to an equivalent retroactive-injection attack, because JLL URLs and content hashes are frozen at release time and verified on download.
• We are continuing to monitor the LiteLLM project's security communications for further disclosures.

---

Incident 3: axios npm Package Compromise

Background

On 31 March 2026, it was publicly disclosed that two versions of axios — a widely used JavaScript HTTP client library — had been compromised on npm. Specifically, versions 1.14.1 and 0.30.4 were found to contain malicious code that dropped a Remote Access Trojan (RAT) onto affected systems. The malicious versions were subsequently removed from npm, but any developer or CI system that had installed them during the exposure window could have been affected.

The incident was documented by StepSecurity:

• StepSecurity blog post: https://www.stepsecurity.io/blog/axios-compromised-on-npm-malicious-versions-drop-remote-access-trojan
• axios GitHub issue: https://github.com/axios/axios/issues/10604

JuliaHub uses axios as a transitive dependency — it is pulled in by our internal @juliacomputing/pkg-authentication package, which in turn specifies axios@"^1.4.0" as a dependency. This range would, under normal auto-update conditions, have permitted installation of the compromised version.

JuliaHub's Exposure

We opened an immediate incident response on 31 March 2026 and performed the following checks:

• Developer machines: We ran osquery Fleet queries across all managed developer workstations searching for the malicious versions (1.14.1 and 0.30.4) directly in npm package tables, across all known npm paths (including nvm and Homebrew), and via direct filesystem search for axios/package.json inside node_modules. No instances of the compromised versions were found on any machine.
• Specific indicators of compromise: We explicitly searched for the known malware drop file (/tmp/ld.py on Linux/macOS) across developer machines and CI runners. None were found.
• CI runners: We manually ran filesystem checks on all GitHub CI machines. No compromised versions were detected.
• Installed versions confirmed safe: Versions found in our codebases — including axios 1.14.0, 1.13.6, and 1.13.5 — were all confirmed unaffected. The compromised version was specifically 1.14.1; 1.14.0 is clean.
• Platform code: We verified that no members of the platform team had the compromised packages installed.

Conclusion: No JuliaHub systems, developer machines, or CI runners were found to have the compromised axios versions installed. No indicators of compromise were detected.

Preventive Actions Taken

• We verified that our Renovate configuration enforces a 3-day cooldown on npm package updates, which would have prevented same-day adoption of a newly published malicious version. This cooldown will be retained.
• We initiated a review of our npm configuration to add a no-install-script setting, which prevents execution of package install scripts — a common malware vector — along with an update delay window.
• We identified that automated tooling can be applied across JuliaHub repositories to further harden transitive dependency management, consistent with the approach already used for pinned GHA actions.
• We initiated a broader review of package-lock.json hygiene to ensure all transitive npm dependencies are locked and reviewed before update.

---

General Recommendations for Customers

Regarding npm and supply chain hygiene:

• Always commit and track package-lock.json files to ensure reproducible dependency trees.
• Consider adding a delay window (minimum 3–5 days) before auto-applying npm dependency updates via Renovate or Dependabot, to allow time for the community to identify malicious releases.
• Where possible, add ignore-scripts=true to your .npmrc to prevent execution of install scripts from third-party packages.

Regarding GHA and CI security:

• Pin all third-party GitHub Actions to a specific commit hash rather than a mutable version tag.
• Regularly audit your workflow token permissions and avoid granting broader scopes than necessary.

---

Contact

If you have questions about this advisory or believe you may have been affected by any of the above incidents, please contact our security team at security@juliahub.com.

---

JuliaHub is committed to transparency in security matters. We will issue updates to this advisory if new information becomes available.

Summary

Security vulnerabilities have been reported in a few Julia packages: HTTP.jl, Gitforge.jl, Github.jl and Registrator.jl. Updated versions of all these packages with fixes for the known vulnerabilities are now available.

Details of vulnerabilities

1. The URIs.jl and HTTP.jl packages allowed the construction of URIs containing CR/LF characters. If user input was not otherwise escaped or protected, this can lead to a CRLF injection attack.

   More information here: https://github.com/JuliaWeb/HTTP.jl/security/advisories/GHSA-4g68-4pxg-mw93

   This has been assigned CVE-2025-52479

   A few notes on this particular issue:

   • The Downloads package in the standard library is NOT vulnerable to this issue.
   • The forthcoming 2.0 version of HTTP.jl is also not vulnerable to this issue.

2. Lack of validation for user provided fields in GitForge.jl

   More information here: https://github.com/JuliaWeb/GitForge.jl/security/advisories/GHSA-g2xx-229f-3qjm

   This has been assigned CVE-2025-50178

3. Command and Argument injection in Registrator.jl

   More information: https://github.com/JuliaRegistries/Registrator.jl/security/advisories/GHSA-589r-g8hf-xx59 and https://github.com/JuliaRegistries/Registrator.jl/security/advisories/GHSA-w8jv-rg3h-fc68

   These have been assigned CVE-2025-52483 and CVE-2025-52480

   Each of these above issues were found by splitline from the DEVCORE Research Team.

4. Lack of validation for user-provide fields in GitHub.jl

   More information: https://github.com/JuliaWeb/GitHub.jl/security/advisories/GHSA-jg9p-c3wh-q83x

   This has been assigned CVE-2025-52569

   This was found by Dilum Aluthge based on similarities with the issues in GitForge.jl

Impact on the JuliaHub platform

The Registrator.jl vulnerability when stacked on the HTTP.jl and GitForge.jl issues had the potential to create RCE in the JuliaHub platform. The hosted platform on JuliaHub.com was patched within a day of the vulnerability report. This advisory is being released after a few days to allow patched releases of all the related open source packages.

The impact to client instances of the JuliaHub platform (Team, Enterprise, and Self-Managed tiers) is much more limited, since Registrator functionality is available only to existing users authenticated by SSO. Updates to these instances are in process, in coordination with the clients.

We have verified from the logs that we can see no attempt being made to exploit this issue, either on JuliaHub.com or on any of the client instances that we host.

Finally, v6.9.2 of the JuliaHub platform has been released with updated dependencies that patch all these vulnerabilities.

Recommendation to customers

• Upgrade all internal Julia codebases to use HTTP.jl v1.10.16 and URIs.jl v1.6.0 immediately.
• Upgrade to JuliaHub platform v6.9.2 when possible.

Summary

A backdoor was identified in the popular XZ data compression library. We do not believe any JuliaHub infrastructure or any Julia users are affected by this issue.

Background

A thread in oss-security mailing list reported that the XZ Utils project was affected by a backdoor: one of the current maintainers of the project appeared to have injected malicious code, included in versions v5.6.0 and v5.6.1 of the xz-utils package, that under certain circumstances could potentially compromise an OpenSSH client and obtain login credentials to remote systems. This issue has been assigned CVE-2024-3094.

Details

The open source Julia ecosystem

The backdoor is added to a binary build of XZ under the following conditions:

1. The target system is x86_64-linux-gnu (Linux kernel, on x86_64 architecture, using glibc as standard C library)
2. the compiler is GCC
3. the build system detects dpkg or rpm are being used

Julia packages use binary builds of native C libraries that are created using our own infrastructure, which are distributed as so-called jll packages. This build system does not meet condition 3 above, and therefore we believe Julia users who have installed XZ using the Julia package manager are not vulnerable to this backdoor. The announcement of the security exploit in the oss-security mailing list includes a script to detect whether a build of liblzma is vulnerable, by checking a certain pattern is present in the hexadecimal dump of the library. We have verified our builds of liblzma.so in XZ_jll v5.6.0 and v5.6.1 do not contain the known pattern. Please talk to your JuliaHub support contact if you want to run this analysis yourself.

In the abundance of caution however, the XZ_jll package versions 5.6.0 and 5.6.1 have been removed from the Julia package registry. They can no longer be installed – users are able to install only versions up to 5.4.6.

The Juliahub Platform

All JuliaHub platform servers and container images are derived from Debian stable. The vulnerable packages were only added to Debian unstable, and therefore did not make it into any of our builds or images.

JuliaHub enterprise customers should talk to their support contacts if they need any assistance in extracting the list of users who have installed XZ versions v5.6.0 and v5.6.1 from the logs. Again, this is only for an abundance of caution, as we do not believe those users are vulnerable.

Acknowledgements

• The original announcement by Andres Freund: https://www.openwall.com/lists/oss-security/2024/03/29/4
• The Julia ecosystem bulletin by Mosè Giordano: https://discourse.julialang.org/t/psa-backdoor-in-xz-utils-and-relevance-for-the-julia-ecosystem/112328