Hex 2.5 hardens the supply chain

Hex 2.5 landed on 29 June 2026 with one theme: making it harder for a compromised release to reach your build. Supply chain attacks on package registries have become routine. The usual pattern is that someone compromises a maintainer account or a build pipeline, publishes a tampered release, and automated tooling pulls it into thousands of projects within hours, long before anyone notices. Hex 2.5 ships three layers of defence, most of which need no configuration.

Advisories in the terminal

mix deps.get and mix deps.update now flag known-vulnerable packages inline, tagging them "VULNERABLE" with a short summary and deduplicating advisories across databases. It is exactly how we recently caught and cleared a handful of advisories on this very site. Resolving deps looks like this now:

Resolving Hex dependencies...
Resolution completed in 0.42s
  mdex 0.11.7 VULNERABLE!
    EEF-CVE-2026-54889 (MEDIUM)
    aka: CVE-2026-54889, GHSA-4383-7xfp-gpph
    Unsanitized URL schemes in MDEx Quill Delta output allow javascript: injection (XSS)
    https://osv.dev/vulnerability/EEF-CVE-2026-54889
    EEF-CVE-2026-53426 (HIGH)
    aka: CVE-2026-53426, GHSA-923r-7vf4-5vw8
    Atom-table exhaustion denial-of-service via JSON parse_document in MDEx
    https://osv.dev/vulnerability/EEF-CVE-2026-53426
Found packages with security advisories

For CI, mix hex.audit inspects your lockfile and exits non-zero if any dependency carries an advisory or has been retired, so a vulnerable release fails the build instead of slipping through:

$ mix hex.audit
Advisories:
  phoenix_live_view 1.2.6 - EEF-CVE-2026-58228 (MEDIUM)
    aka: CVE-2026-58228, GHSA-5cgh-g58j-m9cq
    Scheme validation bypass in Phoenix.LiveView.Utils leads to XSS via <.link>
    https://osv.dev/vulnerability/EEF-CVE-2026-58228

Found packages with security advisories

Bumping phoenix_live_view to a patched release and re-running it prints "No retired or security advisory packages found", and the build is green again. This is all on for every project with nothing to configure.

Release-age cooldown

The cooldown withholds very recently published versions from resolution, giving the community time to catch a bad release before it lands in your deps:

# mix.exs
hex: [cooldown: "7d"]

Durations look like 7d, 2w or 1mo. It never touches already-locked dependencies, and there is an escape hatch when a current version turns out to be unsafe. mix hex.outdated shows which updates are being held and when they become eligible.

Dependency policies

Organisations can publish a signed policy and enforce it across every project that opts in, restricting releases by advisory severity, retirement reason, or release age. mix hex.policy show summarises the active policy, and mix hex.policy why <package> explains, version by version, why something is blocked.

Package authors need do nothing for any of this. Consumers get the advisories and the cooldown for free, which is a rare thing in security: a genuine improvement you pick up just by upgrading.