A newly disclosed Windows Defender vulnerability, tracked as CVE-2026-50656 and dubbed RoguePlanet, has raised concerns across the cybersecurity community after a working proof-of-concept (PoC) exploit was released before a security patch became available. The exploit was published on GitHub by security researcher Nightmare Eclipse on June 10, 2026, only hours after Microsoft issued its June Patch Tuesday updates.  The RoguePlanet flaw affects Microsoft Defender and carries a CVSS 3.1 base score of 7.8 (AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H). It is categorized under CWE-362, which covers race conditions caused by improper synchronization of shared resources. Microsoft has acknowledged CVE-2026-50656 and confirmed that a fix is in development, but as of June 18, 2026, the company has not announced a release timeline. 

Nightmare Eclipse Releases RoguePlanet After Previous Disclosures 

The publication of CVE-2026-50656 followed the researcher’s earlier coordinated disclosures involving two other Defender vulnerabilities, CVE-2026-45586 (GreenPlasma) and CVE-2026-45585 (YellowKey), both of which were addressed during June’s Patch Tuesday cycle.  According to Nightmare Eclipse, the decision to publicly release RoguePlanet without a prior coordinated disclosure period stemmed from dissatisfaction with what the researcher described as slow response times within Microsoft’s bug bounty process. As a result, defenders are now dealing with a publicly documented exploit targeting one of the world’s most widely deployed endpoint security platforms before a patch is available. 

How CVE-2026-50656 Works 

At its core, CVE-2026-50656 exploits a Time-of-Check to Time-of-Use (TOCTOU) race condition inside Microsoft Defender’s file-processing workflow. During a scan, Defender checks a file path and later reopens the file for analysis. The RoguePlanet exploit takes advantage of the gap between those two actions by replacing the original file with a malicious payload. Because Microsoft Defender operates under the SYSTEM account, a successful race condition allows the substituted payload to execute with SYSTEM-level privileges. The exploit reportedly works on fully patched Windows 10 and Windows 11 systems. Although exploitation requires local authenticated access, attackers often obtain such access through phishing campaigns, browser exploits, or stolen credentials. The PoC is not guaranteed to succeed on every attempt because it depends on winning the race condition. However, Nightmare Eclipse noted that automated retry mechanisms can make exploitation reliable in practical scenarios.

Why RoguePlanet Matters 

Local privilege escalation vulnerabilities such as CVE-2026-50656 are frequently used in post-compromise attack chains. Once attackers gain limited access, vulnerabilities like RoguePlanet can elevate permissions to full system control. This enables actions such as disabling security software, extracting credentials from LSASS, establishing persistence, and moving laterally across networks.  Microsoft stated that it is working on a “high-quality patch” but has not committed to an out-of-band release, leaving open the possibility that CVE-2026-50656 could remain unpatched until a future Patch Tuesday update.  Organizations are advised to monitor Windows Event Logs for unexpected SYSTEM-level process creation, deploy EDR detections for rapid file-substitution activity, enforce least-privilege access controls, restrict unnecessary development tools, enable Attack Surface Reduction rules in block mode, block known PoC hashes, and deploy Microsoft’s fix immediately once it becomes available. 

Security researchers have unveiled ChatGPhish, a newly documented vulnerability concept that demonstrates how browser-based prompt injection can influence ChatGPT page summaries and potentially expose users to phishing, tracking, and social engineering attacks.  The research builds on earlier findings involving AI-assisted email summarization. In previous investigations, researchers examined how attacker-controlled content embedded in emails could manipulate an LLM into generating misleading responses within trusted interfaces. The latest study extends that concept beyond email and into the browser, introducing a broader attack surface where ordinary web pages can act as delivery mechanisms.  According to the researchers, the core issue is not the web page itself, but the transfer of trust that occurs when content from a third-party website is processed and presented inside a trusted ChatGPT interface. As a result, pages containing attacker-controlled instructions may influence the model's output and lead users to interact with content that appears legitimate. 

Browser-Based Prompt Injection Expands the Attack Surface 

Unlike email attacks, which often encounter spam filters, secure email gateways, attachment controls, and user awareness training, browser-based attacks require far less interaction. A victim simply needs to visit a web page and request a summary through an AI-powered browsing feature.  The researchers noted that modern browsing activity regularly involves websites such as documentation portals, GitHub repositories, blog posts, SaaS dashboards, help centers, marketing pages, and internal portals. Any of these surfaces could potentially become delivery mechanisms if their content is passed into an LLM summarization workflow.  During testing, researchers used Firefox as the entry point. After visiting a page and invoking ChatGPT's page summarization feature, the page content was supplied to the model. Once processed, attacker-controlled instructions embedded within the page influenced the generated summary. The resulting response was then displayed inside ChatGPT, complete with rendered links and images.  The researchers emphasized that this is not a Firefox vulnerability. Firefox merely provides access to the page summarization workflow. They argue that the broader risk applies to any browser-integrated LLM system that renders untrusted Markdown content without clear separation from trusted assistant-generated output. 

How ChatGPhish Demonstrates Phishing Within ChatGPT 

One of the primary demonstrations involved injecting a fake account security notification into a legitimate web page.  In the proof-of-concept scenario, an attacker appended instruction-like content to a page that otherwise appeared legitimate, such as a GitHub README, article, documentation page, or product website. The injected content instructed the model to follow a specific response structure whenever the page was summarized.  The malicious prompt directed the assistant to generate a standard page summary followed by an account alert claiming that "a new device was added to your account: Chrome on Linux (Pristina)." The message then included a clickable link directing users to an attacker-controlled website.  Researchers observed that ChatGPT generated a legitimate summary of the page before appending the attacker-controlled alert. The phishing URL appeared alongside the summary in a manner that could be mistaken for an official notification issued by the platform itself.  The study argues that this behavior demonstrates how a prompt injection vulnerability can transform external web content into seemingly trustworthy assistant-generated information. 

QR Code Delivery Creates a Cross-Device Threat 

The ChatGPhish research also explored a more sophisticated attack method involving QR codes.  While traditional phishing links remain visible to users and are often subject to browser protections, QR codes shift the interaction to a separate device. Users scanning a code with a smartphone may never see the underlying destination URL until after the scan occurs.  In the demonstrated scenario, researchers replaced the phishing hyperlink with a Markdown image containing a QR code hosted in an attacker-controlled Amazon S3 bucket. Because the ChatGPT renderer automatically fetched and displayed the image, the QR code appeared directly within the assistant's response.  The payload instructed the model to generate an account alert and embed the QR code image beneath it. Once rendered, victims could scan the code and be redirected to an attacker-controlled destination without triggering desktop browser protections such as URL previews, domain reputation checks, blocklists, or password-manager warnings.  Researchers argue that this QR-code technique represents a more dangerous variation of the attack because it bypasses many traditional desktop security controls. 

Cybersecurity researchers have revealed critical details about a newly identified RCE vulnerability, tracked as CVE-2026-3854, affecting both GitHub’s cloud infrastructure and GitHub Enterprise Server deployments. The flaw, which carries a high CVSS score of 8.7, could allow an authenticated user to execute arbitrary code on affected systems with a single crafted git push command.  The vulnerability, discovered by researchers at Wiz, exposes a command injection flaw within GitHub’s internal handling of user-supplied data. Specifically, the issue lies in how push options, key-value strings sent during a git push operation, were processed. 

What is CVE-2026-3854 RCE Vulnerability? 

According to an advisory from GitHub, “During a git push operation, user-supplied push option values were not properly sanitized before being included in internal service headers.” Because the internal header format relied on a delimiter character that could also appear in user input, attackers could manipulate these values to inject additional metadata fields.  This weakness opened the door for exploitation of the RCE vulnerability, allowing attackers to gain access to a repository, including one they created themselves, to execute arbitrary commands on the server handling the request.

How the RCE Vulnerability Worked 

At the core of CVE-2026-3854 is improper input sanitization. During a typical git push, metadata such as repository type and processing environment is passed between internal services. This metadata is encoded using a delimiter, specifically a semicolon.  However, because user-controlled push options were inserted into this metadata without sufficient filtering, an attacker could craft inputs containing the delimiter. This allowed them to inject additional fields into the internal X-Stat header.  By chaining multiple malicious values, researchers demonstrated that an attacker could: 

• Override the environment in which the push operation was processed  
• Bypass sandboxing protections designed to restrict execution  
• Ultimately achieve remote code execution on the server  

This made the flaw particularly dangerous, as it required minimal effort to exploit—a single command could trigger the attack. 

Timeline: Discovery and Rapid Response 

The CVE-2026-3854 RCE vulnerability was responsibly disclosed by Wiz on March 4, 2026. GitHub’s response was notably swift.  In a detailed blog post, Alexis Wales explained:  “On March 4, 2026, we received a vulnerability report through our Bug Bounty program from researchers at Wiz describing a critical remote code execution vulnerability affecting github.com, GitHub Enterprise Cloud, GitHub Enterprise Cloud with Data Residency, GitHub Enterprise Cloud with Enterprise Managed Users, and GitHub Enterprise Server.”  GitHub’s internal security team began validation immediately. Within 40 minutes, they had reproduced the issue and confirmed its severity. By 5:45 p.m. UTC, the root cause had been identified, and by 7:00 p.m. UTC—less than two hours after validation—a fix was deployed to GitHub.com. 

Affected Systems and Patch Availability 

The RCE vulnerability CVE-2026-3854 impacted a wide range of GitHub products, including: 

• GitHub.com  
• GitHub Enterprise Cloud  
• GitHub Enterprise Cloud with Data Residency  
• GitHub Enterprise Cloud with Enterprise Managed Users  
• GitHub Enterprise Server  

While cloud-hosted services were patched automatically on March 4, 2026, GitHub Enterprise Server required manual updates. Fixes were released in the following versions: 

• 3.14.25  
• 3.15.20  
• 3.16.16  
• 3.17.13  
• 3.18.8  
• 3.19.4  
• 3.20.0 or later  

Users of GitHub Enterprise Server are strongly advised to upgrade immediately to mitigate the risk associated with this RCE vulnerability. 

No Evidence of Exploitation 

Following the patch deployment, GitHub conducted a thorough forensic investigation to determine whether CVE-2026-3854 had been exploited in the wild.  A key indicator of exploitation was the triggering of an unusual internal code path—one not used during normal operations. GitHub analyzed telemetry data and found: 

• All instances of this anomalous behavior were linked exclusively to the Wiz researchers’ testing  
• No unauthorized users triggered the exploit  
• No customer data was accessed, modified, or exfiltrated  

This provided strong assurance that the RCE vulnerability had not been abused before disclosure. 

Defense-in-Depth Improvements 

Beyond fixing the input sanitization issue, GitHub identified an additional weakness. The exploit relied partly on a code path that should not have been accessible in the affected environment. Although it existed within the server’s container image, it was intended for a different configuration. GitHub removed this unnecessary code as part of its remediation efforts. This additional hardening ensures that even if a similar vulnerability emerges in the future, its impact would be significantly reduced.

Recommendations for GitHub Enterprise Server Users 

For organizations using GitHub Enterprise Server, exploitation of CVE-2026-3854 would require an authenticated user with push access. As a precaution, GitHub recommends: 

• Reviewing /var/log/github-audit.log for suspicious push operations  
• Checking for push options containing semicolons (;)  
• Upgrading to the latest patched version without delay  

The fallout from the Axios npm supply chain attack continues to widen, with OpenAI issuing a detailed response outlining its exposure and remediation steps. The Axios npm supply chain attack, reported by The Cyber Express on April 1, has since been linked to North Korea’s Lazarus Group, significantly expanding the scope and impact of the incident. Attribution was confirmed by Google Threat Intelligence Group, which identified the activity under UNC1069, a financially motivated group active since at least 2018.

OpenAI Confirms Limited Exposure to Axios npm Supply Chain Attack

In its official statement, OpenAI said, “We recently identified a security issue involving a third-party developer tool, Axios, that was part of a widely reported, broader industry incident⁠.” The company clarified that while it was affected by the broader Axios npm supply chain attack, there is no evidence of compromise to user data or internal systems. “We found no evidence that OpenAI user data was accessed, that our systems or intellectual property was compromised, or that our software was altered,” the statement added. The exposure occurred on March 31, 2026, when a GitHub Actions workflow used in OpenAI’s macOS app-signing process executed a malicious version of Axios (v1.14.1). This workflow had access to sensitive code-signing certificates used for validating OpenAI applications like ChatGPT Desktop, Codex, Codex CLI, and Atlas.

Certificate Rotation and macOS App Updates

As a direct response to the Axios npm supply chain attack, OpenAI has initiated a full rotation of its macOS code-signing certificates. While internal analysis suggests the certificate was likely not exfiltrated, the company is treating it as potentially compromised. To mitigate any residual risk, OpenAI is requiring users to update their macOS applications. Older versions of affected apps will lose support and functionality after May 8, 2026. Updated versions will carry new certificates to ensure authenticity. This move is designed to prevent threat actors from distributing malicious software disguised as legitimate OpenAI applications, a known risk in supply chain attacks involving code-signing materials.

Investigation and Security Measures

OpenAI engaged a third-party digital forensics and incident response firm to investigate the impact of the Axios npm supply chain attack. The company also coordinated with Apple to block any new notarization attempts using the old certificate. Additional steps taken include:

• Publishing new builds of all affected macOS applications
• Reviewing all past software notarizations for anomalies
• Ensuring no unauthorized modifications were made to distributed software

The company confirmed that no malicious applications signed with its certificate have been identified so far.

Root Cause: GitHub Workflow Misconfiguration

The root cause of OpenAI’s exposure to the Axios npm supply chain attack was traced to a misconfiguration in its GitHub Actions workflow. Specifically, the workflow relied on a floating tag instead of a fixed commit hash and lacked a minimum release age for dependencies, both of which increased the risk of pulling compromised packages. This highlights a broader industry issue where development pipelines remain vulnerable to upstream compromises, especially in open-source ecosystems.

No Impact on User Data or Other Platforms

OpenAI emphasized that the incident is limited strictly to macOS applications. There is no impact on iOS, Android, Windows, Linux, or web-based services. The company also reassured users:

• No user data or API keys were compromised
• No passwords need to be changed
• No malware signed as OpenAI has been detected

What Happens Next

OpenAI will fully revoke the old certificate on May 8, 2026, after a 30-day transition window. This approach is intended to minimize disruption while ensuring users have adequate time to update their applications. The company noted that any software signed with the old certificate will be blocked by macOS security protections after revocation, further reducing the risk of misuse.

Growing Impact of Axios npm Supply Chain Attack

The Axios npm supply chain attack highlight the escalating risks tied to third-party software dependencies. With attribution pointing to a state-sponsored group, the incident reflects how supply chain attacks are increasingly being leveraged for financial and strategic objectives. As organizations continue to rely heavily on open-source libraries, the incident serves as a reminder of the need for stricter dependency management, secure development practices, and continuous monitoring of software pipelines.