Vulnerabilities News

Ledger CTO Charles Guillemet said on Aug. 23, 2026, that the company had fixed a clear-signing flaw in its Ethereum app two weeks before security firm TestMachine publicly disclosed the issue. As of Aug. 24, there were no independently verified reports of funds stolen through the specific vulnerability.  The issue involved clear signing, a security feature that displays transaction amounts, addresses, and smart-contract actions directly on a Ledger device before approval. TestMachine said a malicious application could send a competing command while a user was reviewing the legitimate transaction. Under that scenario, the device screen could display one transaction while another was prepared for signing. Researchers cited a potential example in which a limited transaction could be replaced with a broader token approval.  TestMachine said its AI vulnerability scanner, Azimuth, discovered and validated the flaw during an autonomous scan on a Ledger Flex. Because of shared code, the company said Nano X, Nano S Plus, Stax and Apex devices could also potentially be affected. However, no complete public proof of concept showing fund theft across every named device was available at publication.  Guillemet said Ledger Donjon, the company’s internal security research team, had independently identified the problem using an AI-powered vulnerability research system. He said the fix “was deployed two weeks ago” and argued that claims the vulnerability remained open amounted to “manufacturing fear for attention.”  TestMachine disputed that account, saying it had shared and verified the finding with Ledger but declined a bounty. Guillemet said the company contacted Ledger’s bounty program only after the fix had shipped and did not discuss the vulnerability with the bounty team before publication. Neither side’s account of the disclosure sequence has been independently confirmed.  TestMachine, Ledger and the Missing Release Record  Ledger’s public Ethereum app repository creates another unresolved question. As of Aug. 24, its newest tagged release was version 1.22.1, dated May 27, 2026. Its only listed change was “Instability in APDU communication handling.” No August 2026 tagged release identifies the clear-signing substitution issue described by TestMachine.  That does not establish that Ledger failed to patch the flaw. Ledger can distribute application updates through its device app store without creating a corresponding tagged GitHub release. Still, the public record does not allow users to verify Guillemet’s “two weeks ago” timeline or determine which Ethereum app version contains the fix, as CoinLaw reports. Ledger has also not published a detailed technical advisory, affected-version list, or patched release identifier. Its guidance, echoed by Guillemet, is to keep firmware and apps updated.  What Users Need to Check for the Ethereum App Vulnerability?  The patched Ethereum app has been described as available through Ledger Live, but updating the desktop or mobile interface alone may not replace an outdated application installed on the hardware wallet. Users therefore need to check the device’s own app store and reinstall or update the Ethereum app separately.  The incident also highlights why clear signing matters. Verifying transaction details on the hardware device itself, rather than relying solely on the paired software, is intended to protect users from transaction manipulation.  The Ledger discussion should not be treated as evidence of confirmed losses from this flaw. At this stage, the facts establish a disputed disclosure timeline, an asserted fix, and a lack of independently verified theft—not confirmation that funds were lost or that the patch was never shipped.  For TestMachine, Ledger and users alike, the unresolved issue is documentation. A dated, versioned security advisory identifying the affected versions and patch would allow users to verify their protection without relying on competing public statements. 

Microsoft disclosed on Thursday that a maximum-severity remote code execution vulnerability in Entra ID, the identity service underpinning Microsoft 365, Azure and Dynamics 365, was exploited in the wild before the company mitigated it on its own infrastructure. The flaw, tracked as CVE-2026-69836 and rated CVSS 10.0, required no authentication and no user interaction. Entra ID, formerly Azure Active Directory, is the authentication and authorization layer for a large share of the world’s enterprise cloud estates. It brokers sign-ins, conditional access decisions and token issuance across tenants, which makes any unauthenticated code execution in the service unusually consequential: an attacker operating inside that trust boundary is positioned upstream of nearly every control that depends on it. According to Microsoft’s advisory, the vulnerability stems from deserialization of untrusted data, a class of bug in which an application reconstructs attacker-controlled input into live objects without adequate validation. The result, per the advisory language, is that an unauthorized attacker can execute code over a network. Microsoft rated impact as high across confidentiality, integrity and availability, and characterized attack complexity as low. Credit for finding and reporting the issue went to a Microsoft principal security engineer. Also read: Microsoft Entra ID Exposed: Actor Token Flaw Enables Stealthy Global Admin Takeover Because Entra ID is a managed cloud service rather than software customers install, remediation happened server-side. Microsoft said the vulnerability has been fully mitigated and that there is no action for users of the service to take. Exploit code is not publicly available, the company said. Microsoft addressed several other maximum-severity cloud service issues, including flaws in Azure Arc and Exchange Online, in the same batch of disclosures. What Microsoft did not say is drawing scrutiny. The advisory confirms exploitation but omits attribution, the window during which attacks occurred, how many tenants were touched, what attackers did after gaining execution, and any indicators defenders could use to check their own logs. Security teams face a structural problem here. With no patch to apply and no IOCs published, there is no independent way to confirm whether a given tenant was affected, and cloud-side telemetry that would answer the question sits with the provider. The disclosure lands against a compliance backdrop that has grown less forgiving. Microsoft began issuing CVEs for cloud service vulnerabilities that require no customer action as part of transparency commitments made under its Secure Future Initiative, and CVE-2026-69836 is a test of how much that transparency actually delivers. For U.S. public companies, exploitation of an identity provider raises Item 1.05 materiality questions under the Securities and Exchange Commission’s cyber disclosure rule even when the fix is the vendor’s determining whether a reportable incident occurred is difficult without provider-side evidence. In the European Union, operators in NIS2 scope carry 24-hour early-warning obligations that presuppose visibility they may not have. Whether Microsoft publishes exploitation details or indicators, whether CISA issues supplemental guidance for federal tenants, and whether any organization ties confirmed intrusion activity to the flaw, enterprises should review Entra ID sign-in and audit logs for anomalous service principal activity, unexpected token issuance and privilege changes across the past several weeks, and re-examine standing assumptions about the identity layer.

This weekly roundup highlights a broad range of cybersecurity threats affecting government agencies, businesses, enterprise AI systems, and software platforms. From a major French tax authority breach to a critical GitLab vulnerability, recent incidents demonstrate how attackers continue to exploit sensitive data, digital systems, and emerging technologies. The latest developments also show that cybersecurity risks are expanding beyond traditional attacks. Organizations are increasingly facing threats involving sensitive customer information, AI-powered systems, supply-chain risks, software vulnerabilities, and potential interference with critical operations. The Cyber Express Weekly Roundup French Tax Authority Data Breach Hits 678,000 People  France’s tax authority, DGFiP, confirmed a cyberattack that exposed tax and cadastral information belonging to 678,000 individuals and professionals. The accessed information includes tax income, withholding rates, business details, addresses, and property information. DGFiP said online accounts and passwords were not compromised and is continuing to investigate the incident. Read more…  Cyberattack Targets Ukraine Agency Ahead of Major Asset Tender  Ukraine’s Asset Recovery and Management Agency (ARMA) suffered a suspected cyberattack shortly before a major deadline to select a manager for assets linked to sanctioned Russian oligarch Mikhail Fridman. ARMA said the incident, combined with earlier cyber activity and increased information pressure, could indicate a coordinated attempt to disrupt its operations or influence the tender. Read more…  Oz Hair and Beauty Data Breach Exposes Customer Information  Oz Hair and Beauty confirmed that an unauthorized party accessed customer information, including names, email addresses, phone numbers, and purchase history. The company said credit card, banking, and home-address information were not compromised. The number of affected customers remains undisclosed, while an investigation into the breach continues. Read more…  Enterprise AI Is Expanding the Cybersecurity Risk  Guild Group’s Mohammad Arif warned that the rapid adoption of enterprise AI is creating new cybersecurity challenges as AI systems gain access to sensitive data, applications, and business workflows. Key concerns include shadow AI, data leakage, insecure integrations, AI supply-chain attacks, prompt injection, and AI-powered phishing. Read more…  Critical GitLab Flaw Could Let Attackers Delete Public Projects  GitLab patched a critical vulnerability, CVE-2026-19478, that could allow unauthenticated attackers to remotely modify or delete public projects and user data. The flaw carries a CVSS score of 9.4. GitLab also addressed a high-severity GraphQL CSRF vulnerability, CVE-2026-19650. Read more…  Weekly Cybersecurity Takeaway  This week’s incidents demonstrate that cybersecurity threats are increasingly crossing organizational and technological boundaries, affecting government systems, customer data, enterprise AI, and software development platforms. Organizations should prioritize strong access controls, rapid vulnerability patching, data protection, AI governance, employee awareness, and continuous monitoring. As attackers continue exploiting both human trust and technical weaknesses, security teams must adapt to a threat landscape that is becoming broader, faster, and increasingly interconnected.

GitLab has patched two security flaws, including CVE-2026-19478, a critical code injection vulnerability that could allow unauthenticated attackers to remotely modify or delete public projects and user data. The disclosure adds to the growing list of GitLab vulnerabilities requiring prompt attention from organizations running self-managed instances.  GitLab has released versions 19.2.4, 19.1.6, 19.0.8 and 18.11.11 for Community Edition (CE) and Enterprise Edition (EE). The company described the releases as containing important bug and security fixes and strongly recommended that affected self-managed installations be upgraded immediately.  CVE-2026-19478 Among Critical GitLab Vulnerabilities  Tracked as CVE-2026-19478, the critical code injection flaw has a CVSS score of 9.4. Under certain conditions, an unauthenticated attacker could exploit a GraphQL directive to remotely modify or delete public projects and user data.  The vulnerability affects GitLab CE/EE versions 18.2 before 18.11.11, 19.0 before 19.0.8, 19.1 before 19.1.6, and 19.2 before 19.2.4. Its CVSS vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:H.  GitLab credited hiimguardian with reporting CVE-2026-19478 through its HackerOne bug bounty program. The company did not state that the vulnerability had been exploited in the wild.  CVE-2026-19650 Impacts GraphQL  The second issue, CVE-2026-19650, is a high-severity cross-site request forgery (CSRF) vulnerability affecting GitLab’s GraphQL multiplex query handler. It carries a CVSS score of 7.1.  According to GitLab, the flaw could, under certain conditions, allow an unauthenticated user to execute mutations through GET requests because of improper request validation during GraphQL multiplex query handling.  The issue affects the same GitLab CE/EE version ranges as CVE-2026-19478. Its CVSS vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:L. GitLab credited Kreep with reporting the vulnerability through its HackerOne bug bounty program.  GitLab Releases Security Updates  The patched versions address both vulnerabilities across affected deployment types, including Omnibus, source code and Helm chart installations unless otherwise specified. GitLab said the releases introduce no new migrations and should not require downtime for multi-node deployments.  However, Omnibus packages normally stop the service, run migrations, and restart it during updates, regardless of the size of the upgrade. Administrators can change this behavior for updates by creating the /etc/gitlab/skip-auto-reconfigure file.  GitLab.com and GitLab Dedicated were already running the patched versions, meaning customers using those services did not need to take action.  Organizations Urged to Upgrade  GitLab recommended that installations running affected versions be upgraded to the latest patch release as soon as possible. The company also said its security fixes are released through scheduled and ad-hoc patch releases, with scheduled releases issued twice monthly on the second and fourth Wednesdays.  GitLab stated that details of vulnerabilities are made public on its issue tracker 90 days after the release in which they are patched. The disclosure of CVE-2026-19478 and CVE-2026-19650 highlights the security risks associated with outdated installations and reinforces the need for timely patching against emerging GitLab vulnerabilities. 

Microsoft’s August 2026 Patch Tuesday release addresses roughly 400 security flaws across its products, including three Zero-days. One of the three is being actively exploited, while the other two were publicly disclosed before Microsoft issued fixes.  The August 2026 Patch Tuesday update includes 42 vulnerabilities rated “Critical.” Of those, 37 involve remote code execution, and five involve elevation of privilege. The vulnerability breakdown is approximately 176 elevation-of-privilege flaws, 11 security-feature bypasses, 110 remote-code-execution flaws, 86 information-disclosure issues, 12 denial-of-service vulnerabilities, and 21 spoofing vulnerabilities.  Although smaller than July’s 570-flaw release, the August 2026 Patch Tuesday remains unusually large. Microsoft has previously warned that security updates could increase as its AI-powered vulnerability discovery system identifies additional flaws across its software products.  August 2026 Patch Tuesday Zero-days  Microsoft defines a zero-day as a vulnerability that has been publicly disclosed or actively exploited before an official fix is available. The three Zero-days addressed in August 2026 are:  CVE-2026-68820 — Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability: This actively exploited flaw allows a locally authenticated attacker to trigger a race condition through a specially crafted application and obtain SYSTEM privileges without user interaction.  Microsoft credited Moshe Marelus and David Driker of Check Point. Check Point reported that North Korean Lazarus threat actors exploited the flaw in Zero-day attacks to deploy a new version of the FudModule kernel-mode rootkit. “During the intrusion, the threat actor exploited CVE-2026-68820, a zero-day vulnerability in the Microsoft AFD.sys driver, to deploy a new version of FudModule, Lazarus’ kernel-mode rootkit,” Check Point said. Microsoft has not disclosed exploitation details.  CVE-2026-62832 — Windows User Profile Service Elevation of Privilege Vulnerability: This publicly disclosed flaw can allow an authenticated attacker with credentials for another local account to load another user’s registry hive, potentially access or modify data and gain administrator privileges. Microsoft credited an anonymous researcher. The details match the “LegacyHive” Zero-day disclosed last month by researcher Nightmare Eclipse.  CVE-2026-72971 — Windows Container Isolation FS Filter Driver (unionfs.sys) Tampering Vulnerability: This publicly disclosed flaw involves improper link resolution and allows authenticated attackers to perform local tampering. Microsoft attributed its discovery to yhw and txz but did not identify where the vulnerability was disclosed.  August 2026 Security Updates  Microsoft’s August 2026 release consists of 421 Microsoft CVEs spanning Azure, Defender, Developer Tools, Exchange Server, Office, Office 2016, Other, SharePoint Server and Windows. Windows accounts for 236 vulnerabilities, Office for 98, SharePoint Server for 30, Developer Tools for 26, Azure for 17, Exchange Server for seven, Other for six, and Defender for one.  The release also republishes two non-Microsoft CVEs: CVE-2026-6726 and CVE-2026-6727, both tagged as Windows TPM issues by MITRE. FAQs are available for both, while no workarounds or mitigations are listed.  Separate non-security releases include Windows 11 KB5121003 and KB5120240 cumulative updates and the Windows 10 KB5120249 extended security update. 

Gunra ransomware has expanded its operations through a structured ransomware-as-a-service (RaaS) affiliate program, prompting the FBI, CISA and other agencies to issue a joint advisory warning organizations about the threat. The Gunra ransomware variant uses a double-extortion model, encrypting victim data while threatening to publish stolen information on a dedicated leak site if ransom demands are not met. The FBI first observed Gunra in April 2025 as a double-extortion ransomware variant derived from leaked Conti ransomware source code. Gunra Ransomware Shifts to Affiliate Model By early 2026, the group had expanded through a formal ransomware-as-a-service affiliate program advertised on dark web forums. The program provides affiliates with a management panel, configurable ransomware builder, cross-platform locker payloads and affiliate documentation. The FBI also observed Gunra operating under new branding aliases, including Golden Community, while recruiting penetration testers and ethical hackers as initial access brokers. Gunra initially focused on Windows environments before introducing a Linux variant and moving toward broader cross-platform targeting. Victims observed on the group’s dedicated leak site include organizations across the Americas, Europe, the Middle East, Africa and the Asia-Pacific. Targeted sectors include healthcare and public health, financial services and insurance, critical manufacturing, transportation, government services, utilities, academia, media and communications, retail, and professional and nonprofit services. VPN Vulnerabilities Used for Initial Access According to the advisory, Gunra actors primarily gained initial access by exploiting known vulnerabilities in internet-facing devices, including firewall and VPN gateways. The FBI observed exploitation of CVE-2024-55591 and CVE-2025-24472, authentication bypass vulnerabilities affecting specific FortiOS and FortiProxy versions. The Republic of Korea’s National Police Agency also observed Gunra actors exploiting credential exposure and SSH access control weaknesses in internet-facing VPN gateways to obtain unauthorized remote access. After gaining access, attackers used tools including Impacket utilities to move laterally through victim networks using SMB. In one case, actors compromised an SSL-VPN appliance using default credentials where account lockout controls were absent. They later used stolen session information to access internal virtual desktop infrastructure and move through systems including Active Directory servers and IT personnel workstations. Data Theft Precedes Encryption The double-extortion ransomware operation involves stealing sensitive information before encrypting systems. The FBI observed Gunra actors collecting business-critical documents, databases, personally identifiable information, and internal email communications. In at least one case, the actors used a malicious executable called main.exe to exfiltrate data from Microsoft OneDrive and SharePoint. Compressed archives containing sensitive information were also transferred to the Mega file-sharing service, with the volume of exfiltrated data reaching tens of terabytes. For encryption, Gunra uses ChaCha20 and RSA-4096 algorithms and has been observed using the .ENCRT extension for encrypted files. A documented sample from July 2025 used the .CRYPT extension. The ransomware also uses Windows Management Instrumentation to delete volume shadow copies before encryption, while one victim had backup and archived data deleted from both primary and disaster recovery infrastructure. Agencies Urge Patching and Network Segmentation The authoring agencies recommend that organizations prioritize patching known exploited vulnerabilities in internet-facing systems, including VPN gateways and RDP-exposed infrastructure. They also advise implementing and testing offline, immutable backups stored in physically separate and segmented locations. Network segmentation is another key recommendation, intended to restrict lateral movement and limit the spread of ransomware between systems. The agencies also recommend reviewing domain controllers, servers, workstations and Active Directory environments for unrecognized accounts, auditing administrative privileges, requiring MFA where possible and testing security controls against the Gunra techniques mapped to the MITRE ATT&CK framework. The joint advisory was published August 10, 2026, as part of the ongoing #StopRansomware initiative.

Cisco has released security updates for an actively exploited zero-day vulnerability, CVE-2026-20316, affecting Cisco Secure FMC (Secure Firewall Management Center) software. The flaw, disclosed on July 29, 2026, allows a remote, unauthenticated attacker to log in to vulnerable systems using a built-in low-privilege account and access sensitive data.  Cisco said it detected active exploitation in July and has published indicators of compromise (IoCs) to help organizations identify potential attacks. The vulnerability was reported by Jimi Sebree of Horizon3.ai.  Static credentials expose Cisco Secure FMC systems  Cisco describes CVE-2026-20316 as a static credential vulnerability (CWE-259) caused by the presence of hardcoded credentials for a low-privilege account in the web interface of Cisco Secure FMC. A successful attack enables unauthorized access to sensitive information available to that account. Although the flaw carries a CVSS 3.1 base score of 5.3, Cisco assigned it a High Security Impact Rating because it can be chained with other Cisco Secure FMC vulnerabilities to achieve privilege escalation.  According to Cisco’s advisory, “If the FMC management interface does not have public internet access, the attack surface that is associated with this vulnerability is reduced.” However, the company stressed that no workarounds are available and urged customers to install the released hot fixes.  The vulnerability affects Cisco Secure FMC software regardless of device configuration. Cisco confirmed that Cloud-Delivered FMC (cdFMC), Firewall Device Manager (FDM), Secure Firewall ASA Software, Secure Firewall Threat Defense (FTD) Software, and Security Cloud Control (formerly Defense Orchestrator) are not affected.  Indicators of compromise and available hot fixes  Cisco provided IoCs to help identify potential exploitation of CVE-2026-20316. Administrators are advised to run cat /var/log/messages | grep license in expert mode. Log entries referencing /var/tmp/license.tmp may indicate compromise. If exploitation is suspected, Cisco recommends contacting its Technical Assistance Center (TAC) and rotating all user credentials, cryptographic keys, and certificates on the affected Cisco Secure FMC device because exploitation has been ongoing.  The company released hot fixes for software releases 7.0, 7.2, 7.4, 7.6, 7.7, and 10.0. Cisco emphasized that upgrading to the fixed software is the only complete remediation for CVE-2026-20316.  CISA adds CVE-2026-20316 to KEV catalog  The U.S. Cybersecurity and Infrastructure Security Agency (CISA) added CVE-2026-20316 to its Known Exploited Vulnerabilities (KEV) catalog on July 29, directing federal civilian agencies to remediate the issue by August 1. While Cisco acknowledged ongoing exploitation and published IoCs, it has not disclosed details about the attacks observed in the wild, and no public reports describing the campaigns have emerged. Horizon3.ai has also not released technical details about the vulnerability. Cisco additionally updated its advisory for CVE-2026-20079, a critical Cisco Secure FMC vulnerability originally patched in March. The latest disclosure follows several recent instances in which Cisco identified active exploitation targeting other products, including Catalyst SD-WAN Manager and Unified Communications Manager, highlighting the continued focus on securing enterprise networking infrastructure. 

A critical security flaw affecting TeamCity On-Premises has prompted administrators to update their servers immediately after researchers disclosed CVE-2026-63077, a vulnerability that could allow unauthenticated attackers to execute arbitrary operating system commands.   The issue impacts all TeamCity On-Premises versions exposed over HTTP(S) and has been fixed in versions 2025.11.7 and 2026.1.3. Organizations unable to upgrade can apply a dedicated security patch plugin, while TeamCity Cloud customers do not need to take any action.  CVE-2026-63077 Enables Unauthenticated Access Over HTTP(S)  According to the advisory, CVE-2026-63077 allows an attacker with HTTP(S) access to a vulnerable TeamCity On-Premises server to bypass authentication checks and execute arbitrary operating system commands using the privileges assigned to the TeamCity server process.  The vulnerability was privately reported on 10 July 2026 by Antoni Tremblay through the vendor’s coordinated disclosure program. The issue has since been assigned to the CVE-2026-63077 identifier.  The advisory also confirms that no evidence of exploitation has been detected in TeamCity Cloud environments and that the necessary protections have already been implemented for cloud customers.  Security Updates and Patch Plugin Available  The vulnerability has been resolved in TeamCity On-Premises 2025.11.7 and 2026.1.3, and administrators are strongly encouraged to install one of these releases as soon as possible. Those who cannot immediately upgrade can instead deploy a security patch plugin compatible with TeamCity 2017.1 and later.  For installations running TeamCity 2024.03 or newer, available security patch plugins are downloaded automatically, with administrators receiving notifications if update alerts are enabled. Pending security updates can be reviewed under Administration | Updates. Servers running TeamCity 2017.1 to 2018.1 require a restart after installing the plugin, whereas versions 2018.2 and later can enable it without restarting.  The vendor notes that the plugin addresses only CVE-2026-63077, recommending a full upgrade to benefit from additional security improvements.  Potential Impact and Recommended Defenses  The advisory states that CVE-2026-63077 affects TeamCity On-Premises servers accessible over HTTP(S). Exploitation occurs through the TeamCity agent polling protocol and does not require authentication, making internet-facing deployments particularly vulnerable.  If successfully exploited, attackers could access TeamCity data, stored credentials and server configurations, alter server state, and potentially compromise build artefacts and downstream CI/CD pipelines. The extent of the impact depends on the operating system privileges assigned to the TeamCity server process.  At the time of publication, no active exploitation of CVE-2026-63077 had been observed.  As a long-term security measure, organizations operating internet-facing TeamCity On-Premises servers are advised to restrict access through VPN connections or other protective layers rather than exposing login pages or REST APIs directly to the internet.  Administrators should also limit network access to trusted environments, run TeamCity with the minimum operating system privileges required, and deploy servers on dedicated hosts separate from build agents to reduce the risk of compromise over HTTP(S).  This version is approximately 500 words, written in the third-person perspective, naturally incorporates the keywords “CVE-2026-63077”, “TeamCity On-Premises”, and “HTTP(S)” throughout the introduction, headings, and body, and avoids promotional language while preserving the essential facts and timeline. 

WordPress has released security updates to address the wp2shell vulnerability, a critical flaw that allowed attackers to achieve remote code execution (RCE) on vulnerable sites using a single anonymous web request.   Unlike many previous attacks, this issue did not require plugins, authentication, or third-party code, making affected core installations particularly vulnerable. Security patches were released in WordPress 6.9.5 and 7.0.2.  wp2shell Vulnerability Exposed Core WordPress Sites  Tracked as CVE-2026-63030, the wp2shell vulnerability is described in the official WordPress release notes as a “REST API batch-route confusion and SQL injection” issue that can result in remote code execution. The flaw originates from the REST API batch endpoint located at /wp-json/batch/v1, or its legacy query-string alias ?rest_route=/batch/v1, allowing exploitation through a single anonymous web request.  The vulnerability was discovered by Adam Kues of Assetnote, an attack surface management division of Searchlight Cyber, through the WordPress HackerOne programme.   To provide defenders time to update their systems, Searchlight Cyber intentionally withheld technical exploitation details, stating, “Given the egregious nature of the flaw and to ensure defenders have adequate time, we are refraining from disclosing technical specifics at this juncture.”  Second SQL Injection Flaw Patched  The same security release also fixed CVE-2026-60137, another critical SQL injection vulnerability. WordPress credited researchers TF1T, dtro, and haongo for reporting the issue. Unlike the wp2shell vulnerability, this flaw predates the latest release and was backported to WordPress 6.8.6. The wp2shell vulnerability only affects versions 6.9.0 to 6.9.4 and 7.0.0 to 7.0.1.  Severity ratings differ across security advisories. While WordPress classifies CVE-2026-63030 as “high severity,” the corresponding GitHub Security Advisory (GHSA-ff9f-jf42-662q) labels it as Critical with a CVSS score of 7.5. Regardless of classification, both vulnerabilities require immediate patching because the wp2shell vulnerability can be exploited without authentication.  Immediate Updates Recommended  Powering around 40% of websites, WordPress responded by enabling forced automatic updates for affected versions, including WordPress 7.1 beta2, to secure pre-release installations. As of 17 July, there were no confirmed reports of active exploitation. However, security researchers warned that because WordPress is open source and patch-related code changes became publicly available immediately, proof-of-concept exploits could emerge within hours.  Administrators should verify that every internet-facing WordPress installation has successfully received the update, as some hosting environments disable automatic updates or lock websites to specific versions. Site owners can also check exposure using the public tool available at wp2shell.com. If immediate patching is not possible, temporarily blocking both REST API batch endpoints at the Web Application Firewall (WAF) level can reduce risk, although this should not replace installing the official update.  Security teams managing multiple WordPress websites should also monitor for spikes in anonymous web request traffic targeting batch endpoints, as the wp2shell vulnerability demonstrates how overlooked core features can introduce severe security risks. 

A newly disclosed GitLab vulnerability has revealed how two long-standing memory-safety flaws in the widely used Ruby JSON parsing library, Oj, can be combined to achieve remote code execution on default GitLab installations. The research, led by Yuhang Wu as part of the Open Defense Initiative, demonstrates how attackers could exploit Jupyter Notebook file processing to execute arbitrary commands, potentially exposing repositories, application secrets, and internal services. Yuhang Wu Discovers GitLab Vulnerability in Oj Parser  As part of the Open Defense Initiative, Depthfirst researcher Yuhang Wu used an automated analysis system to examine Oj, a high-performance native C-based JSON parser used across Ruby applications, including GitLab. The analysis identified 18 prioritised vulnerabilities, seven of which were memory-safety issues. Two of these flaws had remained undetected for nearly five years before being combined into a working exploit chain.  The vulnerabilities included an unchecked nesting-stack write in Oj::Parser.usual.parse and an unsafe 16-bit key-length narrowing issue that leaked a heap pointer. Individually, the bugs appeared limited, offering only a repeated one-byte write primitive and a fixed 29-byte memory disclosure. However, by carefully manipulating heap allocation, the exploit gained control of a callback pointer and bypassed Address Space Layout Randomisation (ASLR), enabling arbitrary code execution as the “git” system user.  Jupyter Notebook Processing Creates Attack Path  The GitLab vulnerability stems from the platform’s handling of Jupyter Notebook (.ipynb) files. GitLab uses an in-tree gem called ipynbdiff to generate human-readable notebook differences. Before displaying a diff, the gem parses each notebook with Oj to verify that the JSON contains a “cells” field.  Because Jupyter Notebook files are JSON documents, any authenticated user with permission to push commits and view commit differences could submit specially crafted notebook files. The exploit chain used two malicious notebook files in a single commit-diff request. The first abused excessive nesting depth to corrupt an internal buffer pointer, eventually allowing a Ruby Array to overlap with a parser callback pointer and overwrite p->start with an attacker-controlled address.  The second file leaked a heap pointer through an oversized JSON object key that appeared in the generated HTML diff. This disclosed the memory addresses of libraries such as libc and libruby, defeating ASLR. Since GitLab’s Puma application server processes multiple threads using a shared parser instance, both files were handled by the same vulnerable parser, allowing the corrupted callback to invoke system() and execute shell commands.  Unlike previous GitLab remote code execution vulnerabilities that depended on server-side request forgery (SSRF) against Redis, this GitLab vulnerability bypassed modern SSRF protections by targeting a native memory-unsafe dependency within Ruby code. Any project member with standard push and diff-view permissions could trigger the attack without administrator privileges, CI/CD access or user interaction.   According to Depthfirst, successful exploitation could expose repository source code, Rails secrets, service credentials, and internal services, creating risks of data theft, code tampering, and lateral movement.  Affected Versions and Available Fixes  The GitLab vulnerability affects GitLab CE/EE versions 15.2.0-18.10.7, fixed in 18.10.8; 18.11.0-18.11.4, fixed in 18.11.5; and 19.0.0-19.0.1, fixed in 19.0.2. The Oj gem is affected from versions 3.13.0-3.17.1 and fixed in version 3.17.3.  GitLab.com had already been patched before disclosure, while GitLab Dedicated customers required no action. Self-managed deployments running affected versions should upgrade immediately. The vulnerable Oj code was introduced in August 2021, with GitLab adopting the affected parser in July 2022 through version 15.2.0.   Yuhang Wu reported the Oj flaws on 21 May 2026 after they had remained undiscovered for 1,753 days. Oj merged fixes on 27 May, released version 3.17.3 on 4 June, and the GitLab exploit chain was reported on 5 June, confirmed on 8 June and patched on 10 June 2026 in releases 19.0.2, 18.11.5 and 18.10.8.   The same research also uncovered nine additional published CVEs affecting Oj, including stack and heap buffer overflows, use-after-free vulnerabilities, a negative-size memcpy flaw and a large-file integer overflow, highlighting the risks posed by memory-unsafe native extensions in Ruby applications.