CVE-2026-82584: ANSI escapes forge mix

CISO Take

Igniter's `mix igniter.install` shows an anti-typosquatting confirmation panel meant to let developers verify a Hex package's real publisher and download count before adding it as a dependency, but versions 0.8.1 through 0.8.3 only strip newlines from publisher-controlled metadata, leaving ANSI escape sequences intact. A malicious or typosquatted package author can embed cursor-movement and line-erase codes in fields like the description or owner username to overwrite the panel's contents, forging a trusted author name and inflated download count while hiding the real, suspicious ones. There is no CVSS score, no CISA KEV listing, no EPSS data, and no public exploit or scanner template, so this reads as a low-noise supply-chain trust bypass rather than an actively exploited flaw — but it defeats the exact control developers rely on to catch malicious dependencies at install time. The realistic risk is concentrated in Elixir/Phoenix shops (including any building AI-adjacent tooling with Igniter-based generators) who trust the panel as a gate; upgrade to igniter 0.8.4 or later, and until then treat the confirmation panel as untrustworthy and manually verify package ownership and history on hex.pm before approving installs.

Sources: NVD GitHub Advisory ATLAS

What is the risk?

Low technical complexity, no authentication or special access required, and no code execution is granted directly by this bug — it is a UI-trust/deception vulnerability (CWE-150, improper neutralization of escape/control sequences) that enables a downstream social-engineering step. Severity is unscored by NVD, not in CISA KEV, and no EPSS/exploit/Nuclei signal exists, indicating no observed real-world exploitation. However, the impact ceiling is high: successful deception leads directly to a developer approving installation of an attacker-controlled package, which is a classic supply-chain compromise vector. Overall risk: MEDIUM — low exploitation likelihood today, but the blast radius if exploited is a fully attacker-controlled dependency in the victim's build.

How does the attack unfold?

Malicious package publication

Attacker publishes a typosquatted or newly-registered Hex package embedding ANSI escape sequences in metadata fields such as description and owner username.

AML.T0010.001

Trust panel forgery

When the victim runs `mix igniter.install`, the unsanitized escape sequences overwrite the confirmation panel to display a fabricated trusted author and download count.

AML.T0074

Deceived approval

The developer, relying on the forged panel as an anti-typosquatting safeguard, approves installation of the malicious package.

AML.T0011.001

Supply chain compromise

The malicious package is added to the project's dependency tree, giving the attacker a foothold to execute code within the victim's build or runtime environment.

AML.T0112.001

Malicious package publication

Attacker publishes a typosquatted or newly-registered Hex package embedding ANSI escape sequences in metadata fields such as description and owner username.

AML.T0010.001

Trust panel forgery

When the victim runs `mix igniter.install`, the unsanitized escape sequences overwrite the confirmation panel to display a fabricated trusted author and download count.

AML.T0074

Deceived approval

The developer, relying on the forged panel as an anti-typosquatting safeguard, approves installation of the malicious package.

AML.T0011.001

Supply chain compromise

The malicious package is added to the project's dependency tree, giving the attacker a foothold to execute code within the victim's build or runtime environment.

AML.T0112.001

How severe is it?

CVSS 3.1

N/A

EPSS

0.3%

chance of exploitation in 30 days

Higher than 23% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What should I do?

1 step

Upgrade igniter to 0.8.4 or later immediately, where publisher-controlled metadata fields are properly sanitized before rendering. Until patched, do not rely solely on the mix igniter.install confirmation panel to vet unfamiliar packages — independently check the package's real owner, publish history, and download counts directly on hex.pm or via mix hex.info <package> outside the terminal panel. For detection, audit CI/build logs and terminal session recordings for anomalous ANSI escape sequences in installer output, and flag any recently-approved Igniter installs of low-reputation or newly-published Hex packages for manual re-review. Treat this as a supply-chain hygiene issue: pin dependency versions, review lockfile diffs in PRs, and prefer packages with established maintainer history over new/unverified publishers.

What does CISA's SSVC say?

Decision Track

Exploitation none

Automatable No

Technical Impact partial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Supply Chain Social Engineering Plugin AML.T0010.001 - AI Software AML.T0011.001 - Malicious Package AML.T0074 - Masquerading AML.T0111 - AI Supply Chain Reputation Inflation

Which compliance frameworks are affected?

This CVE is relevant to:

ISO 42001

A.6.2.3 - Third-party and supplier relationships for AI system components

NIST AI RMF

MAP 3.1 - AI system component/dependency risk mapping

OWASP LLM Top 10

LLM05 - Supply Chain Vulnerabilities

Frequently Asked Questions

What is CVE-2026-82584?

Igniter's `mix igniter.install` shows an anti-typosquatting confirmation panel meant to let developers verify a Hex package's real publisher and download count before adding it as a dependency, but versions 0.8.1 through 0.8.3 only strip newlines from publisher-controlled metadata, leaving ANSI escape sequences intact. A malicious or typosquatted package author can embed cursor-movement and line-erase codes in fields like the description or owner username to overwrite the panel's contents, forging a trusted author name and inflated download count while hiding the real, suspicious ones. There is no CVSS score, no CISA KEV listing, no EPSS data, and no public exploit or scanner template, so this reads as a low-noise supply-chain trust bypass rather than an actively exploited flaw — but it defeats the exact control developers rely on to catch malicious dependencies at install time. The realistic risk is concentrated in Elixir/Phoenix shops (including any building AI-adjacent tooling with Igniter-based generators) who trust the panel as a gate; upgrade to igniter 0.8.4 or later, and until then treat the confirmation panel as untrustworthy and manually verify package ownership and history on hex.pm before approving installs.

Is CVE-2026-82584 actively exploited?

No confirmed active exploitation of CVE-2026-82584 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-82584?

Upgrade `igniter` to 0.8.4 or later immediately, where publisher-controlled metadata fields are properly sanitized before rendering. Until patched, do not rely solely on the `mix igniter.install` confirmation panel to vet unfamiliar packages — independently check the package's real owner, publish history, and download counts directly on hex.pm or via `mix hex.info <package>` outside the terminal panel. For detection, audit CI/build logs and terminal session recordings for anomalous ANSI escape sequences in installer output, and flag any recently-approved Igniter installs of low-reputation or newly-published Hex packages for manual re-review. Treat this as a supply-chain hygiene issue: pin dependency versions, review lockfile diffs in PRs, and prefer packages with established maintainer history over new/unverified publishers.

What systems are affected by CVE-2026-82584?

This vulnerability affects the following AI/ML architecture patterns: package/dependency management tooling, CI/CD and build pipelines for AI-adjacent applications, developer environments building Elixir/Phoenix-based AI services.

What is the CVSS score for CVE-2026-82584?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

package/dependency management toolingCI/CD and build pipelines for AI-adjacent applicationsdeveloper environments building Elixir/Phoenix-based AI services

MITRE ATLAS Techniques

AML.T0010.001 AI Software

AML.T0011.001 Malicious Package

AML.T0074 Masquerading

AML.T0111 AI Supply Chain Reputation Inflation

Compliance Controls Affected

ISO 42001: A.6.2.3

NIST AI RMF: MAP 3.1

OWASP LLM Top 10: LLM05

What are the technical details?

Original Advisory

Improper Neutralization of Escape, Meta, or Control Sequences vulnerability in ash-project igniter allows a malicious package publisher to forge the mix igniter.install confirmation prompt. mix igniter.install prints a confirmation panel (an anti-typosquatting safeguard) listing a package's hex metadata before adding it. The panel builder in Igniter.Project.Deps wrote publisher-controlled fields (meta.description, owner usernames, requirement names, version) to the terminal with only newlines stripped. A malicious or typosquatted package can embed ANSI terminal escape sequences (cursor movement, line erase, carriage returns) in its metadata to overwrite the panel, forging trusted author names and download counts while concealing the real ones, so a developer relying on the panel to vet the package is deceived into approving a malicious dependency. This issue affects igniter: from 0.8.1 before 0.8.4.

Exploitation Scenario

An adversary publishes a Hex package with a name closely resembling a popular, trusted library (typosquatting) or compromises/re-registers an existing low-traffic package. In the package's `meta.description` field and owner username, they embed ANSI escape sequences (cursor-up, line-erase, carriage-return) crafted to overwrite the confirmation panel that `mix igniter.install` prints. When a developer runs the install command, the terminal renders a forged panel showing a well-known, trusted maintainer name and a high download count instead of the real, suspicious publisher and low install count. Trusting the panel's anti-typosquatting safeguard, the developer approves the install, adding the malicious package — potentially containing a backdoor, credential harvester, or build-time payload — as a dependency in an AI application's build or deployment pipeline.

Weaknesses (CWE)

CWE-150 Improper Neutralization of Escape, Meta, or Control Sequences CWE-150 Improper Neutralization of Escape, Meta, or Control Sequences

CWE-150 — Improper Neutralization of Escape, Meta, or Control Sequences: The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as escape, meta, or control character sequences when they are sent to a downstream component.

Developers should anticipate that escape, meta and control characters/sequences will be injected/removed/manipulated in the input vectors of their product. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system.
[Implementation] Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylis

Source: MITRE CWE corpus.