Malicious ZIP Archive Delivers Git-Based Remote Code Execution via Hooks and Filters
A developer recently received an unsolicited job offer via LinkedIn from a company called Cryptic Heaven, which claimed to build financial systems for cryptocurrency credit cards. The message directed the recipient to download a contract archive from a provided link, resulting in the file Contract-2026.zip.
Inside the archive were standard documents, a README.md, and a complete .git directory containing multiple branches and custom configuration. The README instructed users to inspect documents across three branches: doc, job, and codebase.
Attack Mechanism
The repository contained a modified .git/config that redirected hooks to .git/objects/interrupt and defined a custom filter named ltr. A post-checkout hook in the hidden directory executed git status after branch switches, while the filter script .git/ltr ran during status checks to download and execute remote code.
The filter script used timing logic and lock files to debounce multiple invocations before launching platform-specific payloads via curl and PowerShell or sh. It preserved file contents by piping input directly to cat, avoiding visible changes to the working directory.
Trigger Scenarios
Execution could occur without deliberate malicious commands through several common developer workflows:
- Opening README.md in Visual Studio Code, which auto-detects the repository and runs git status.
- Using Git-aware terminal prompts that invoke git status upon directory change.
- Following the README instructions to run git checkout on different branches.
The attack targeted both Unix-like systems and Windows, relying on Git for Windows to interpret shell scripts even from PowerShell or CMD environments.
Implications
By delivering a full local Git repository in ZIP format rather than a clone URL, the attackers preserved malicious local configuration that standard cloning would discard. Analysts recommend inspecting .git/config, .git/info/attributes, and custom hooks before opening unknown repositories in any IDE.
Related articles
OIDC-Based Push Deployment on VPS Removes SSH Keys from CI While Enforcing Strict Isolation
A new self-hosted deployment system called cd enables secure continuous delivery to single Linux VPS hosts running Docker without storing any long-lived secrets in CI repositories. The architecture relies on short-lived OIDC JWT tokens issued by GitHub Actions or GitLab CI, verified on the target server through JWKS public keys. The server component cdd performs token validation, archive checks, resource-limited builds inside BuildKit, health checks, and automatic rollback on failure. All containers are launched with read-only root filesystems, dropped capabilities, no-new-privileges, and network binding restricted to 127.0.0.1 behind Caddy or Nginx. Administrative control is provided by the cdctl CLI that registers projects, sets RAM/CPU limits, and manages DNS records via Porkbun integration. The entire solution avoids external databases, web panels, and persistent secrets while enforcing one-repository-to-one-application boundaries.
Stolen Credentials Poison cPGuard Update Channel, Turning Security Software into Data Theft Backdoor
Attackers used compromised OPSSHIELD credentials to hijack the cPGuard update distribution network on November 2 at 02:06 UTC, injecting malicious scripts into versions 5.88.12 through 5.88.19. The poisoned updates targeted Linux servers running the security tool, which holds root privileges on hosting provider and cloud infrastructure machines. The script harvested /etc/shadow, /etc/passwd, MariaDB/MySQL root credentials from my.cnf, root shell history containing API tokens, and SSH authorized_keys files before exfiltrating them via the vendor's own infrastructure. A persistent backdoor was also dropped at /var/tmp/.cpg91511_sh. OPSSHIELD detected the intrusion within 12 hours and halted distribution, but confirmed that 32 customer servers had their data accessed. The incident highlights risks of relying on static credentials for security product update pipelines without code signing or behavioral restrictions.
Polymarket Suffers Supply Chain Attack via Compromised DebugBear Monitoring Script
Attackers compromised DNS records of DebugBear, a real user monitoring provider, to inject malicious JavaScript into Polymarket pages. The script extracted wallet data and trading credentials from browser storage, then used the platform's official relayer to execute unauthorized withdrawals totaling approximately $2.7 million across 737 wallets. No smart contract vulnerabilities were exploited; all 985 unauthorized transactions carried valid user signatures. The incident occurred on October 29 and was resolved within an hour after trading was halted, with Polymarket returning $3.9 million including compensation. This attack class matches the 2023 Ledger Connect Kit compromise, highlighting risks from third-party scripts in browser sessions. Polymarket has since committed to stricter CSP policies, script pinning, and sandboxing. The case underscores that browser-based sessions with full API privileges remain a critical trust boundary in crypto platforms.
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.