Polymarket Suffers Supply Chain Attack via Compromised DebugBear Monitoring Script
On October 29, users of the prediction market platform Polymarket reported unauthorized withdrawals and forced position liquidations. The platform quickly shifted to cancellation-only mode before halting trading and the relayer service that processes orders. Within roughly one hour, operations resumed, but the root cause was not a direct breach of Polymarket infrastructure or smart contracts.
The compromise targeted DebugBear, a third-party real-user monitoring service whose script measures page load performance. Attackers altered the vendor’s DNS records and began serving malicious JavaScript from the same origin. Because the script ran under the correct domain and origin, browsers treated it as legitimate first-party code.
The injected script read account data, wallet addresses, and trading API credentials from browser storage. It located the React trading client and its signer component, then submitted withdrawal requests through Polymarket’s official relayer. Depending on account type, the code either transferred open positions directly or liquidated them first before moving funds. All 985 unauthorized transactions used valid wallet signatures and passed through the legitimate relayer, making them indistinguishable from authorized activity at the blockchain level.
Bitquery analysis identified 737 affected wallets with combined losses of approximately $2.73 million. Four accounts accounted for 43 percent of the total damage, while 276 smaller accounts lost less than $1,000 each. Polymarket later returned $3.9 million, comprising $2.7 million in direct losses and $1.2 million in compensation for forced sales and trading interruption. Ninety-five percent of impacted wallets received full restitution by October 30 without needing to file claims.
The attack shares the same attack class as the December 2023 compromise of the Ledger Connect Kit library, where a supply-chain substitution allowed malicious code to reach decentralized applications. In both cases, attackers did not need private keys; they only needed code that the victim’s own page loaded with full session privileges.
Polymarket has announced plans to implement stricter Content Security Policy rules, script integrity pinning, sandboxing of third-party code, and continuous integrity monitoring. Security researchers note that reducing reliance on external scripts, enforcing least-privilege browser permissions, and separating trading and withdrawal functions remain the most effective defenses against this vector.
Related articles
Approved Stamp: How Container Images Pass Rigorous Security Checks Before Reaching Production
DevSecOps engineer Vitaly Matveev from ecom.tech describes a comprehensive lifecycle process for securing Docker images from build to deployment. The approach combines base image validation through a centralized manifest, Dockerfile checks via Infra Gate, Security Quality Gate results stored as attestations in Harbor, and cryptographic signing only after all checks pass. Kyverno policies in production Kubernetes clusters enforce signature verification and block unsigned or unapproved images. Daily automated scans of base images using EPSS scoring detect new vulnerabilities and notify responsible platform teams. The system ensures traceability from pipeline ID to running pod while maintaining a developer-centric workflow with clear remediation guidance.
Passwordless Kubernetes Image Pulling with Artifact Keeper via ServiceAccount Tokens
Kubernetes 1.34 and later enables kubelet to forward a pod's ServiceAccount token to an external image credential provider plugin, allowing the plugin to exchange it for short-lived read-only credentials from a compatible registry. Artifact Keeper, an open-source Rust-based OCI and package registry, implements an OIDC provider that validates these tokens and issues temporary credentials without requiring imagePullSecrets in manifests. The approach follows zero-trust principles by eliminating long-lived secrets that can leak across namespaces or clusters. A custom credential provider binary handles the token exchange, enforces audience restrictions, and redacts sensitive data from logs. The solution requires specific ClusterRole permissions for nodes, kubelet flags, and registry-side OIDC mappings that bind Kubernetes namespaces to read-only groups. Testing on kind 1.34.3 confirmed successful pulls for authorized ServiceAccounts and clear 401 errors for unauthorized ones when imagePullPolicy is set to Always.
Malicious Code Injected into LiteLLM Open Source AI Package via Supply Chain Attack
The open-source generative AI tool LiteLLM had malicious code inserted into its official distribution packages, enabling credential theft and remote code execution. The compromise affected version 1.107.0 released on October 21, 2026, and was delivered through legitimate channels in a classic software supply chain attack. Seven malicious wheel files were uploaded to PyPI, while official container images on Docker Hub and GitHub Container Registry were also tainted. Security firm JFrog discovered that the malware steals a wide range of secrets including cloud credentials, SSH private keys, browser-stored passwords, development tokens, and AI service API keys from LiteLLM's database. The code also supports execution of externally fetched payloads and abuses Python's startup mechanisms to run even when the application itself is not loaded. This marks the second supply chain incident involving the project in 2026, following a separate event in March.
GhostAction Campaign Compromises 790 GitHub Repositories via Malicious Workflows
Researchers from OpenSourceMalware have identified 790 publicly accessible GitHub repositories containing malicious workflows planted by the GhostAction campaign as of October 9. The campaign abuses trusted maintainer accounts to inject workflows that automatically exfiltrate secrets including AWS access keys and tokens for GitHub, GitLab, Google, Slack, SendGrid, OpenAI, Anthropic, and OpenRouter. Earlier counts by GitGuardian recorded 772 repositories between August 31 and September 30, though the datasets differ and are not cumulative. A separate wave on October 8 impacted 346 repositories linked to two maintainer accounts, including a project belonging to Uber. The malicious workflow runs on code pushes or manual triggers, scans repository files and full Git history for credentials, and sends findings in plaintext to attacker infrastructure. Removing the workflow file does not mitigate exposure, as successful executions already leak credentials and old commits may still contain secrets.