Red Hat Miasma supply chain attack: we detected a Red Hat GitHub credential in stealer logs weeks earlier

Summary

On June 1, 2026, public reporting via The Hacker News disclosed a supply chain attack named "Miasma" affecting Red Hat. Our routine continuous monitoring of infostealer log feeds across underground marketplaces, private Telegram channels, and direct operator sources had already surfaced an active Red Hat GitHub credential and session cookie weeks earlier, on two distinct ingest dates.

This brief documents what we detected, when, how the credential was verified to belong to an active Red Hat employee, and what we can responsibly say about the temporal correlation with the Miasma disclosure. We are publishing this both as a research note and as a concrete example of why infostealer-log monitoring belongs in every supply chain defense program in 2026.

What happened: the Miasma supply chain attack

On June 1, 2026, public disclosure landed of a supply chain compromise dubbed "Miasma: The Spreading Blight," affecting seven npm packages published under the @redhat-cloud-services namespace:

• @redhat-cloud-services/vulnerabilities-client
• @redhat-cloud-services/tsc-transform-imports
• @redhat-cloud-services/topological-inventory-client
• @redhat-cloud-services/sources-client
• @redhat-cloud-services/rule-components
• @redhat-cloud-services/remediations-client
• @redhat-cloud-services/rbac-client

According to coverage at The Hacker News, the first malicious commit appeared on May 29, 2026, three days before public disclosure. Initial access came through a compromised Red Hat employee's GitHub account. The attacker pushed malicious orphan commits directly to the RedHatInsights repositories, bypassing code review entirely.

The malicious payload, embedded as an obfuscated npm preinstall hook, was designed to run on every downstream developer machine and CI/CD environment that installed the affected packages. The hook collects: GitHub Actions secrets, npm tokens, cloud credentials (with explicit targeting of GCP and Azure identities in this variant), Kubernetes and Vault material, SSH keys, Git credentials, and other sensitive files from the host. Exfiltrated data is sent to api.anthropic[.]com:443/v1/api (a domain typosquatting the legitimate Anthropic API endpoint), with GitHub itself used as a fallback channel where encrypted results are committed with threatening messages. The malware also establishes persistence in Claude Code and VS Code environments, and generates uniquely encrypted payloads per infection to frustrate detection.

Attribution is unclear. The cybercrime group TeamPCP previously open-sourced similar attack tooling, which has complicated direct attribution. As of writing, the responsible party has not been publicly named.

What is consistent across recent supply chain compromises in 2026, and what makes credential exposure especially relevant, is the dominant pattern of initial access coming through valid credentials harvested from infected endpoints. Threat actors with access to stealer logs from underground markets do not need to phish, brute-force, or burn an exploit. They simply log in. The compromise of a single engineering account at a major software vendor becomes the patient zero for every downstream consumer that installs the affected packages.

What we detected, and when

Two distinct ingest events brought the same active Red Hat GitHub credential and an accompanying Red Hat session cookie into the WhiteIntel index. Both originated from infostealer logs distributed through the standard underground pipeline (private Telegram channels and underground marketplaces) within the typical 24 to 48-hour window from harvest on the infected endpoint.

• April 13, 2026: first sighting. GitHub credential plus session cookie referencing a Red Hat-managed domain present in the stealer log. The log contained the standard payload (browser-saved credentials, autofill, device fingerprint, malware family attribution).
• May 15, 2026: second sighting referencing the same identity and same Red Hat-managed surface. Distinct log file, distinct source channel, distinct device fingerprint. The repeat sighting suggests either continued infection on the same endpoint or fresh compromise of related infrastructure.

Identifying information for the affected employee has been redacted from both the platform view and this publication out of respect for the individual's safety. The verification process below is described in general terms only.

Verifying the credential is active and belongs to a current employee

Stealer logs surface a lot of credentials. Most are noise: stale accounts, test users, abandoned services. Two independent signals told us the Red Hat exposure was different.

Identity verification via LinkedIn: the GitHub credential's username maps to a public LinkedIn profile of an individual currently employed by Red Hat. The role and tenure listed on the LinkedIn profile are consistent with the level of GitHub access the stolen credential implies. This is a real, active engineering account, not a stale or test artifact. Identifying details for the employee have been redacted from public publication for the safety of the individual.

Technical evidence of an active session: alongside the credential, the stealer log contained an active GitHub session cookie tied to the same identity. An active session cookie is stronger evidence than a credential alone, because it represents a fully-authenticated session (MFA already satisfied at the time of capture) that an attacker can replay directly without re-authenticating.

Verification matters because it changes how seriously to treat the exposure. A leaked credential belonging to a former employee with no current access is a different threat profile than one belonging to an active engineer at a vendor whose downstream consumers number in the millions, paired with a fully-authenticated session cookie that can bypass MFA on replay.

Timeline correlation

Four data points anchor the timeline:

• April 13, 2026: first sighting of the Red Hat GitHub credential and session cookie in infostealer logs (WhiteIntel detection).
• May 15, 2026: second sighting of the same identity in a distinct stealer log (WhiteIntel detection).
• May 29, 2026: first malicious commit pushed to RedHatInsights repositories via a compromised Red Hat employee's GitHub account (per The Hacker News reporting).
• June 1, 2026: Miasma supply chain attack on Red Hat publicly disclosed.

The second WhiteIntel detection on May 15 precedes the first malicious commit on May 29 by 14 days. The first detection on April 13 precedes it by 46 days. Both windows fit the typical dwell-time pattern for credential-based supply chain initial access: a credential surfaces on the dark web, gets acquired by a buyer, the buyer evaluates the target and stages the attack, then operational activity begins.

The reported initial access vector (a compromised Red Hat employee's GitHub account) is structurally identical to what WhiteIntel detected: an active Red Hat GitHub credential plus session cookie inside infostealer logs distributed on the standard underground pipeline.

We are not asserting causation. The specific account whose credential WhiteIntel detected may or may not be the same account that was used in the Miasma initial access. Multiple Red Hat employee credentials could be present in stealer logs at any given time. What we are noting is that a credential with the exact profile of the reported Miasma initial access vector surfaced on the dark web in the weeks leading up to the attack.

What we can and cannot say

Responsible threat research requires being explicit about the limits of what we know. Here are the boundaries:

What we can say

• WhiteIntel detected an active Red Hat GitHub credential and session cookie in infostealer logs on April 13 and May 15, 2026.
• The credential's username maps to a public LinkedIn profile of an active Red Hat employee.
• Both detections preceded the public disclosure of the Miasma supply chain attack on Red Hat.

What we cannot say

• We cannot confirm that this specific credential was the initial access vector used in the Miasma attack.
• We cannot confirm whether the credential was actually exploited by the Miasma operators or by any other actor.
• We cannot independently attribute the Miasma attack to any specific threat actor; that work is for the responding incident response team and Red Hat's own disclosure.
• We cannot publish the specific username, redacted screenshots' uncensored content, or any other detail that would identify the individual employee.

The broader pattern

Regardless of whether this specific credential was used in Miasma, the pattern it represents is the pattern that defines supply chain risk in 2026: an employee endpoint at a major software vendor gets infected with infostealer malware; the malware exfiltrates the full browser credential store including GitHub access and session cookies; those credentials surface on a marketplace within 24 to 48 hours; a buyer with intent to compromise the downstream supply chain purchases the log and uses the credentials directly.

Software vendors are particularly attractive targets because compromise of a single engineering account can lead to malicious code in a release, malicious dependencies in a published package, or backdoored container images. The downstream blast radius is every customer or open-source consumer of the vendor's output.

What organizations should do

Whether or not this credential was used in Miasma, the response playbook for the broader pattern is well-established:

• Continuous monitoring of infostealer log feeds for credentials matching your employee identifiers, vendor identifiers, and source-code-platform accounts (GitHub, GitLab, Bitbucket, npm, PyPI). The 24 to 48-hour distribution window is the prevention opportunity.
• Immediate session revocation when a hit fires, on every platform the credential or cookie was valid for, not just the one referenced in the log. Stealer logs typically contain credentials and cookies for many services from the same infected device.
• Forced password reset and key/token rotation on the affected account, plus audit of recent activity on every service it could access.
• Endpoint investigation for the device that produced the log (the hostname and device fingerprint are in the log). The infection may still be active; the buyer may have purchased multiple logs from the same endpoint over time.
• Vendor supply chain visibility for the organization's own dependencies. Monitor the engineering accounts of critical vendors via lookalike domain monitoring, dark web mention monitoring, and stealer-log monitoring on vendor identifiers.

For organizations interested in continuous monitoring of their own employee and vendor credential surfaces, the credential leak monitoring guide covers the full practice in depth, and the account takeover protection guide covers the downstream identity defense layer.