Trending Topics

Update: GitHub’s Internal Source Code Breach, What TeamPCP’s Hack Really Means For Developers

GitHub has confirmed that a threat actor known as TeamPCP gained unauthorized access to thousands of internal repositories after compromising an employee workstation through a malicious Visual Studio Code extension. While current investigations show no evidence that customer repositories or enterprise data were accessed, the incident demonstrates how a single poisoned developer tool can pivot into a direct hit on a core platform's internal code and infrastructure.

According to GitHub’s statements and multiple security reports, the attacker exfiltrated source code from roughly 3,800 to 4,000 private internal repositories, data that allegedly includes proprietary platform components and sensitive organizational information, which TeamPCP is now advertising for more than $50,000 on underground forums. The entry point is what should concern defenders most: a malicious VS Code extension on an employee machine provided the initial foothold, echoing a broader pattern in TeamPCP's operations where the group abuses developer workstations, software supply chain components, and popular package ecosystems like npm and PyPI to steal credentials and pivot into high-value targets.

GitHub and external reporting both stress that no confirmed customer data exposure has been identified, but the incident surfaces a hard truth for engineering leaders. Internal source code and build pipelines are now primary objectives. Any weak link in the developer stack - from IDE plugins to CI credentials - can be enough to open the door.

For security teams and developers, this breach reinforces the need to treat the IDE and package ecosystem as part of the protected attack surface rather than a trusted default. That means locking down extension installations, monitoring for anomalous developer behavior, aggressively rotating secrets, and tightening controls around internal repositories regardless of whether they are ever intended to be public.

It is also a useful forcing function to revisit fundamentals at scale: enforce least privilege for developer accounts, segment internal build infrastructure from day-to-day workstations, and continuously scan both public and private repositories for exposed secrets. Minimizing blast radius before something goes wrong is considerably easier than explaining the scope of it afterward.

PinTheft And Arch Linux, From Kernel Bug To Point‑And‑Click Root

A newly disclosed Linux kernel flaw, nicknamed PinTheft, has become a serious problem for Arch Linux users after researchers released a working proof-of-concept exploit that elevates any local user to root with a single command. The bug stems from a zero-copy reference-counting issue in the kernel's RDS networking code that can be abused to perform controlled page-cache overwrites. Arch has patched quickly, but many systems remain vulnerable, and the public exploit code makes reliable privilege escalation trivial for anyone who can run local code.

PinTheft arrives alongside other high-profile Linux privilege escalation issues - most notably Copy Fail (CVE-2026-31431) - underscoring how local kernel bugs can quietly become cross-distribution threats that affect containers, cloud workloads, and multi-tenant environments long after patches ship to the original vendor.

The flaw is not remotely exploitable, but that framing understates the risk. What was previously "just" a low-level foothold on an Arch host, a compromised developer box, or a container shell can now be converted into full root access, kernel tampering, and lateral movement with minimal skill. Post-compromise escalation used to require patience and sophistication. With PinTheft, it requires neither.

For defenders, the priority is clear: treat PinTheft and CVE-2026-31431 as urgent kernel issues, inventory where Arch and other affected distributions are running, and move quickly to deploy patched kernels or temporary mitigations such as disabling the vulnerable RDS functionality where feasible.

Until patching is complete, security teams should operate under the assumption that any local account on an unpatched Linux host can become root. That means raising monitoring sensitivity around privilege escalation events, tightening access to shared systems, and treating container compromise as a potential host compromise. A public, weaponized flaw changes the threat calculus - and the response timeline should reflect that.

Drupal Rushes Critical Core Update As Exploit Risk Looms

Drupal has issued a critical core security update for all supported branches, warning that the underlying vulnerability carries a high likelihood of real-world exploitation within hours or days of disclosure. The bug affects specific configurations where Drupal core can be chained with an existing insecure deserialization vulnerability, creating a gadget chain that attackers could abuse for remote code execution or full site compromise if administrators delay patching.

The Drupal Security Team pre-announced the fix in PSA-2026-05-18, rating the issue "highly critical" at 20 out of 25 on their severity scale and urging site owners to reserve time during the May 20 release window to test and deploy updates immediately. Not every site is affected, but those that are may face significant risk.

Past Drupal core bugs make the urgency concrete. CVE-2019-6340 saw proof-of-concept exploits and mass scanning appear within a single day of disclosure, and similar behavior is expected here given Drupal's broad footprint across government, education, and enterprise environments.

For administrators, the immediate steps are to update every supported site to the latest patch level, review JSON API and other web service modules or custom code that could enable unsafe deserialization, and be prepared to apply advisory mitigations if immediate patching is not possible. Given Drupal’s warning that exploits may surface rapidly, teams should treat this as an urgent maintenance window rather than routine scheduling, monitor for unusual requests or unexpected file activity on public-facing sites, and avoid assuming that edge protections alone will hold once working exploit chains are in circulation.

Webworm’s Echocreep And Graphworm, Living Off Your Logs And Cloud For The Long Game

A new report on the Chinese-linked threat group Webworm details how the operators are leveraging two custom malware families - Echocreep and Graphworm - to quietly maintain long-term access to government and enterprise networks by hiding inside legitimate services and log data.

Echocreep focuses on persistence and data theft in Windows environments, using fileless techniques, process injection, and heavy abuse of Windows event logs to stash command-and-control beacons and exfiltrated data where defenders rarely look. Graphworm takes a different approach, using popular cloud platforms and API traffic patterns to blend command traffic into normal outbound connections. Together, they give Webworm a toolkit built for invisibility rather than impact.

Instead of noisy ransomware or destructive payloads, Webworm appears to prioritize stealth and dwell time, chaining living-off-the-land binaries with these implants so that activity appears to be ordinary administration or cloud usage until an operator is ready to move or monetize access. The group's tooling also supports flexible plugins for credential theft, lateral movement, and selective data collection, allowing operators to tailor each intrusion to the target's environment. That adaptability is what makes simple indicator-based defenses largely ineffective once either implant has landed.

For defenders, this campaign reframes how logs and cloud APIs should be treated. Both are potential exfiltration channels, not just telemetry sources. That means instrumenting deeper behavioral analytics around event log tampering, suspicious use of Windows management utilities, and unusual traffic patterns to cloud storage and graph-style APIs.

Tighter segmentation for high-value systems, robust detection for fileless techniques, and continuous review of outbound service allow lists can make life considerably harder for groups like Webworm. Their entire strategy depends on your environment being too noisy and complex for anyone to notice when the logs themselves start working against you.

From Fake Word Online To Full Remote Control

A recent phishing campaign analyzed by researchers shows how a simple “View document in Word Online” lure can quietly turn into full remote control of an employee workstation, without dropping obviously malicious payloads.

The attack starts with a convincing email that redirects victims to a fake Microsoft 365 or Word Online page, then pivots into installing legitimate, digitally signed remote access tools like ScreenConnect, Datto RMM, or other remote management platforms that many enterprises already trust. What makes this wave of activity so dangerous is not sophisticated malware, but how effectively it exploits trust in normal workflows and tools, from Outlook and OneDrive, to corporate RMM agents that defenders often treat as background noise rather than high-risk signals.

Once the victim follows the prompts, attackers obtain persistent remote access using software that blends in with real IT support, allowing them to move laterally, harvest credentials, and stage follow-on fraud or ransomware, all while many security controls see only “legitimate” remote sessions. For security teams, this campaign highlights a critical blind spot: the need to apply least privilege, explicit allow lists, and continuous monitoring to remote access tools, even when they are signed, widely used, and delivered through seemingly benign SaaS flows.

Tightening policies around who can install or run RMM software, alerting on unusual remote sessions, and reinforcing user training on fake cloud login pages can turn these trusted tools back into assets rather than quietly becoming an attacker’s favorite backdoor.