PTC Windchill Vulnerability Exploited in Ransomware Campaign

A Cl0p ransomware affiliate has been observed exploiting a critical-severity remote code execution (RCE) vulnerability in PTC’s product lifecycle management (PLM) platforms Windchill and FlexPLM.

Tracked as CVE-2026-12569 (CVSS score of 9.3), the security defect is described as a deserialization of untrusted data issue that can be exploited without authentication.

Patched on June 17, the bug was flagged as exploited in the wild the next day, when PTC published indicators of compromise (IoCs). It was added to CISA’s KEV catalog at the end of June.

Fresh warnings from ReliaQuest and Ransom-ISAC (in collaboration with eCrime.ch and Defused) show that the vulnerability is now exploited in the wild by a Cl0p affiliate.

“The actor behind these attacks remains unconfirmed. However, the observed tradecraft shares characteristics with previous Cl0p campaigns targeting enterprise applications and high-value data repositories,” ReliaQuest says.

A detailed Ransom-ISAC advisory shows that the attackers have been chaining a “pre-authentication information disclosure in the FlexPLM WSDL endpoint with a server-side flaw in the Windchill login servlet” to achieve RCE and deploy JSP webshells.

Advertisement. Scroll to continue reading.

Following initial access, the hackers have been observed enumerating filesystems, staging data, and exfiltrating data for extortion.

Starting July 20, the attackers have been targeting organizations across the aerospace, automotive, manufacturing, and retail/apparel sectors, Ransom-ISAC’s advisory reads.

As part of the observed campaign, the threat actor has been sending extortion emails with a subject line “Windchill PDMLink module serious data leak” to hundreds of users within the impacted organizations.

“As of 22 July, Cl0p ransomware has not begun listing victims of this latest campaign on their dark web data leak site or has publicly claimed credit for this latest campaign,” Ransom-ISAC says.

Organizations are advised to apply PTC’s patches and to use previously published and newly shared IoCs to conduct threat hunting. They should also follow PTC’s remediation steps.

https://www.securityweek.com/ptc-windchill-vulnerability-exploited-in-ransomware-campaign/

Rockwell Patches Code Execution Flaws in Arena Simulation Software

Rockwell Automation has patched four vulnerabilities in its Arena Simulation software that could let an attacker execute arbitrary code on an affected system, according to advisories published by CISA and Rockwell.

Arena Simulation is a discrete-event simulation software that provides organizations with a virtual environment to model, visualize, and test complex operational workflows, allowing them to identify issues and evaluate process changes before implementing them in production.

The four high-severity flaws — CVE-2026-8085, CVE-2026-8312, CVE-2026-8313, and CVE-2026-8314 — are memory corruption issues stemming from improper validation of user-supplied data that can result in an out-of-bounds write.

SecurityWeek Launches Critical Impact Awards to Recognize Excellence in Industrial Cybersecurity

Successful exploitation could allow an attacker to execute arbitrary code in the context of the current process. Arena versions up to and including 17.00.00 are affected. Rockwell has patched the vulnerabilities in version 17.00.01.

Exploitation is not possible remotely without user interaction — an attacker would need to convince a user to open a malicious file to trigger any of the four bugs.

Advertisement. Scroll to continue reading.

Michael Heinzl, the researcher who discovered the vulnerabilities, told SecurityWeek that the file types involved (Arena experiment and model files) are opened routinely by users as part of normal workflows, meaning a booby-trapped file would not necessarily stand out to an Arena user targeted in a social engineering attempt.

Asked what an attacker could realistically accomplish given that Arena is simulation software rather than a live industrial control system (ICS), the researcher said code execution would be confined to the same privileges as the Arena process itself. Whether an attacker could pivot to more sensitive systems from there would depend on how an organization has deployed and segmented Arena on its network.

The researcher also pointed to Arena’s broad footprint as a reason the flaws matter despite the software not directly controlling physical processes, citing Rockwell’s own customer materials describing adoption among top global supply chain companies, hospitals across multiple countries, and organizations such as defense contractors.

The advisories published by CISA and Rockwell indicate that there is no evidence of in-the-wild exploitation.

Heinzl noted that he has actually identified 17 distinct vulnerabilities in Arena, but Rockwell decided to group them by the affected component, which resulted in only four CVEs being assigned.

The researcher has published 17 advisories on his personal website.

https://www.securityweek.com/rockwell-patches-code-execution-flaws-in-arena-simulation-software/

Is Patching Dead? Vulnerability Management in the Post-Mythos Era

On July 14, 2026, the White House launched Gold Eagle: a federal clearinghouse that uses frontier AI to identify, rank, and coordinate the remediation of software vulnerabilities across government and critical infrastructure before attackers reach them. Bringing together the Treasury, DHS, DoD, open-source software partners, and operators of American critical infrastructure, Gold Eagle’s engine relies on frontier AI—including Anthropic’s Mythos, the same class of system that surfaced critical flaws inside classified U.S. government software during testing.

A government harnessing advanced AI to hunt vulnerabilities is conceding something fundamental: the two-decade model of humans finding and patching vulnerabilities one at a time has stopped keeping pace.

Gold Eagle is the national-scale response. The harder question is: what is required inside your own walls?

What Changed

Mythos is a frontier AI model that surfaces vulnerabilities no prior tool could—from a 27-year-old remote crash in OpenBSD to chained Linux kernel flaws escalating to full system control without human guidance. Anthropic’s roughly 50 Project Glasswing partners have uncovered more than 10,000 high- or critical-severity vulnerabilities in essential software.

That capability would be manageable if it stayed with defenders. It did not. In June 2026, Anthropic released Fable to the public; its access was briefly suspended under US export controls that month before being restored, a signal that frontier vulnerability discovery is now treated as controlled technology, closer to a munition than a SaaS release.

Look at the operational timelines we face:

Advertisement. Scroll to continue reading.

Attacker Speed: In March 2026, Sysdig researchers observed threat actors exploiting a CVE within 20 hours of release without a public proof-of-concept (PoC), weaponizing it from the description alone. Mandiant’s M-Trends 2026 report puts the estimated Mean Time to Exploit (MTTE) at negative seven days—meaning exploits now routinely precede public disclosures.
Defender Lag: The Verizon 2026 Data Breach Investigations Report puts the median time to fix a known-exploited flaw at 43 days (up from 32 the year prior), with only 26% of vulnerabilities ever fully patched.
Extreme Volume: The Forum of Incident Response and Security Teams (FIRST) projects roughly 59,000 new CVEs in 2026—over 160 per day—with Remote Code Execution (RCE) flaws up 130% from last year.

The legacy CVE program was simply not designed for this volume or velocity.

Five Ways The Industry Is Responding

Rethink the patching process. Cisco overhauled its CVE process after recognizing that assessing risk one flaw at a time is unsustainable, shifting to a risk-based disclosure model with umbrella common-weakness categories and a twice-monthly release schedule. The government reached the same conclusion: in June 2026, CISA’s Binding Operational Directive 26-04revoked BOD 22-01 (which mandated strict patching deadlines for everything on the KEV catalog).

Under BOD 26-04, KEV status is now just one of four variables, evaluated alongside:

Public asset exposure
Automated exploitability
Technical impact (partial vs. total control)

We’re moving from patch-everything-on-a-deadline to prioritize-by-realized-risk. As Wendi Whitmore, Chief Security Intelligence Officer at Palo Alto Networks, frames it for boardrooms: “If a vulnerability is published tomorrow with weaponized AI-generated exploit code attached, what is your committed timeline to patch, and who has the authority to invoke it without escalation?”

Reduce the exposure. You cannot patch — or defend — what you cannot see. Discovering assets and mapping your attack surface across internet-facing services, legacy hosts, and shadow deployments remains a foundational step.

However, in the AI era, exposure management goes beyond open ports; it requires constraining what autonomous agents and non-human identities are permitted to do. The July 2026 breach of Hugging Face serves as a cautionary tale: an autonomous AI agent entered through a data-processing pipeline, escalated to node-level access, and moved laterally across internal clusters in a single weekend. The agent did nothing a proper permission model couldn’t have contained—it simply had room to run. Least privilege, tightly scoped tool access, and blast-radius limits for non-human identities (service accounts, API keys, and AI agents) are now as critical as patching itself.

Understand what is actually exploitable. A CVSS 9.8 says nothing about whether the component is internet-facing in your environment, whether an exploit chain reaches sensitive data, or whether controls already mitigate it. Exposure-management platforms map real exploit paths through live environments, turning thousands of findings into a queue a team can work. It is the logic BOD 26-04 imposes: not whether a vulnerability exists, but whether it is exploitable given your architecture.
Validate your exposure and whether your controls hold. SafeBreach analysis of 1.8 million attack simulations found endpoint controls blocking roughly 53% of attacks, while stealthy identity-driven campaigns evaded defenses that reliably stopped ransomware. SafeBreach, Picus, Cymulate,and others, now grouped in the category that Gartner calls Adversarial Exposure Validation — answer what static scanning cannot: “Can an attacker actually exploit this, and what can they reach?”
Prevent vulnerabilities before they ship. AI coding assistants accelerated development and produced a matching surge in vulnerabilities — the 130% RCE rise predates Mythos and Fable, driven by AI-generated code alone. Application-security platforms push findings into the IDE and CI/CD pipeline and use AI to trace each flaw to its root cause and every variant across the codebase. Some, like Pi Security — treat each fix as institutional security memory, so the same vulnerability does not recur in new code.

What To Do Now?

Audit Your Real Patch Times: Measure actual deployment times over the last 90 days for critical CVEs, not policy targets. The delta between policy and reality is your true exposure gap.
Adopt the BOD 26-04 Triage Model:
- Bucket 1 (Incident Response): Actively exploited flaws on internet-facing systems receive immediate incident-level response and compromise checks prior to patching.
- Bucket 2 (Accelerated Remediation): Critical findings without active exploitation evidence undergo fast-tracked deployment.
- Bucket 3 (Standard Maintenance): All remaining flaws run through standard, automated patch cycles.
Test Decision-Making Authority: Run tabletop exercises to time how long executive, operational, and legal sign-offs take for emergency patches. An approval process that takes two hours on a Tuesday afternoon might take twelve hours at 2 am. on a Sunday.
Audit AppSec Against AI Code: Test your current scanners against real samples of AI-generated code. What your scanners miss represents your baseline technical debt.
Rethink Bug Bounties & Disclosure: Many enterprises are pausing bug bounty programs because AI now surfaces more bugs than internal teams can physically validate. Establish an automated triage pipeline for inbound submissions before the sheer volume overwhelms your team.

You cannot out-patch a machine that writes a working exploit from a vulnerability description in twenty hours. That race is over—stop trying to optimize a game you cannot win. The organizations that thrive over the next decade won’t be the ones that simply patch faster. They will be the ones that shrink what is exposed, prioritize what is actually exploitable, prove their controls hold, and prevent flawed code from shipping in the first place.

That requires a security program redesign, not a process optimization.

https://www.securityweek.com/is-patching-dead-vulnerability-management-in-the-post-mythos-era/

Flaw in Adobe Extension With 300M Installs Enabled WhatsApp Data Theft

A highly popular Chrome extension made by Adobe was affected by a vulnerability that could have been exploited to silently steal a user’s WhatsApp chats and contacts.

According to web and browser security firm Guardio, whose researchers discovered and reported the vulnerability to Adobe, an attacker could have stolen users’ WhatsApp data simply by tricking them into visiting a seemingly harmless webpage.

The exploit did not involve a WhatsApp vulnerability, malware deployment, compromised credentials, or access to the targeted device.

The attack, dubbed HermeticReader, affected the Adobe Acrobat Chrome extension, which is installed in approximately 329 million browsers.

Adobe patched the vulnerability in June, shortly after being informed of its existence. The software giant assigned it CVE-2026-48294 and described it as a UXSS-class cross-origin data disclosure vulnerability.

Under the hood, the attack abuses a lack of security checks within the Adobe extension’s internal messaging system. When a victim loads the malicious site, a hidden frame tricks the extension into accepting unverified commands.

Advertisement. Scroll to continue reading.

This allows the attacker to silently write to the extension’s local storage and enable Hermes, a dormant integration engine built by Adobe. Once activated, this engine bridges the gap to WhatsApp Web, enabling the attacker to invisibly scrape the victim’s private chats, contacts, and account details in plain text.

Guardio has published a video showing a HermeticReader attack in action:

[embedded content]

https://www.securityweek.com/flaw-in-adobe-extension-with-300m-installs-enabled-whatsapp-data-theft/

Vibe-Coded Apps Riddled With Exploitable Security Flaws

Vibe-coding is increasing. Vibe-coded apps tend to be buggy. Is this a worrying sign for the future?

Vibe coding, the use of AI to assist or perform code generation, is increasing dramatically. In May 2026, Hostinger reported, “90% of developers regularly use at least one AI tool at work as of January 2026.” This is likely to increase through the basic business pressure that applies to everything: we need more, faster and cheaper.

But while vibe coding is increasing in volume, so are concerns over the security of vibe-developed apps.

Xint.io, the web platform that delivers Theori’s AI driven autonomous pentest code (Xint), decided to analyze vibe-coded apps to quantify what, where, why and how often vibe coding introduces security weaknesses into the apps it touches.

To achieve this, Xint created three tests reflecting the most common AI-assisted development workflows:

on a new app from a well-written spec (greenfield, as with an experienced developer overseeing the process)
on a new app representing the growing incidence of the casual coder saying, ‘just build this’ (greenfield)
on a hardened app (Gnuboard7) to see if hardening introduced new vulnerabilities (the brownfield comparison).

Although Gnuboard7 (a legacy PHP app) is an established app, Xint needed to examine it as if it were an AI-assisted app. So, they migrated it into a Laravel + React architecture “and asked AI to harden it.” The migration created a contemporary baseline so the vulnerabilities found would reflect AI reasoning limits, not legacy quirks.

Each app was given a 30-minute scan for runtime and source code analysis by Xint. It found a total of 434 exploitable security issues: 196 in the greenfield apps, and 238 in the single brownfield app.

Advertisement. Scroll to continue reading.

The primary conclusions reached by Xint.io cover four areas: the most common flaws in AI code; the most common severe flaws; the effect of the app size on the flaws introduced; and has AI made any advances in producing secure code?

Missing controls for rate limiting and DOS are the most common flaws. Resource exhaustion/DOS accounted for 93 of the 434 flaws. Authorization and insecure direct object reference, where users get access to data beyond their permissions, came second with 88 flaws; and access boundary/traversal/SSRF flaws were third with 54.

Such flaws occur when the developer only asks for features. “The impact is not data theft, but in real operation it means runaway server cost or a server an attacker can knock over,” warns the report.

Xint’s advice: “Don’t just check to see if AI code compiles; look for how it performs and the resources it consumes in runtime.”

Secrets exposure is the top source of critical-severity flaws. There were 23 critical findings, with hardcoded or default secrets the most common at 11. Debug-mode RCE accounted for another six.

“Look for hardcoded secrets, such as API keys or PII, embedded in code produced by AI,” advises Xint.

Size matters. “Fine-grained authorization holds up on small apps but breaks as the app grows,” warns the report. While IDOR flaws comprised just 11% of the flaws in the smaller greenfield apps, they comprised 28% in the larger brownfield Gnuboard7 app.

“Double check granular object permissions as the amount of endpoints in an application increases,” suggests Xint.

Despite these continuing flaws being introduced by vibe coding, Xint’s fourth conclusion is that vibe coding AI is improving. Before starting the analysis, Xint had expected to find a large number of injection flaws (SQLi, XSS) and IDOR/BOLA-style access-control bugs. It found the opposite. Injection barely showed up, while IDOR/BOLA flaws were far less common than expected.

“This suggests the foundational labs have genuinely improved in these areas,” comments the report.

The purpose of the Xint study was not to demonstrate that vibe coding introduces bugs (that was already known), nor to stop companies using vibe coding (that isn’t going to happen). However, knowing the most common flaws and understanding how and why they occur can help developers overcome them – either by including prompts that eliminate the flaws and/or checking for their existence after generation.

By understanding the weaknesses in vibe coding, developers can play to its strengths in the future.

https://www.securityweek.com/vibe-coded-apps-riddled-with-exploitable-security-flaws/

Fourth SharePoint Vulnerability Exploited in Past Month’s Wave of Attacks

The in-the-wild exploitation of yet another SharePoint vulnerability has come to light – the fourth in the past month.

The flaw is tracked as CVE-2026-50522, and it was fixed by Microsoft on July 14 with its latest Patch Tuesday updates.

Microsoft describes CVE-2026-50522 as a critical remote code execution vulnerability stemming from deserialization of untrusted data.

“In a network-based attack, an attacker authenticated as at least a Site Owner, could write arbitrary code to inject and execute code remotely on the SharePoint Server,” the company wrote in its advisory.

Threat intelligence firm Defused appears to be the first to have observed exploitation of CVE-2026-50522.

The company reported on July 17 that its honeypots had seen exploitation attempts targeting what appeared to be a zero-day SharePoint vulnerability. However, in an update shared on July 20, Defused said the targeted vulnerability was likely CVE-2026-50522.

Advertisement. Scroll to continue reading.

One day later, shortly after PoC exploit code was released, security firm WatchTowr confirmed active exploitation.

According to the company, threat actors are “stealing machine keys to retain long-term access”.

“Attackers are pulling SharePoint machine keys via a single request,” WatchTowr noted, adding, “Patching is not enough; defenders should rotate credentials on any assets that may have been exposed.”

Microsoft has yet to update its advisory for CVE-2026-50522 to confirm in-the-wild exploitation, but it’s not uncommon for the tech giant to delay updating its advisories after attacks are detected.

The other SharePoint vulnerabilities whose exploitation has come to light in recent weeks are CVE-2026-58644, CVE-2026-56164, and CVE-2026-45659.

CISA recently warned organizations about attacks targeting SharePoint instances. The agency’s Known Exploited Vulnerabilities (KEV) catalog currently includes 13 SharePoint flaws, including five added this year. CVE-2026-50522 has not yet been added to the KEV list.

https://www.securityweek.com/fourth-sharepoint-vulnerability-exploited-in-past-months-wave-of-attacks/

Oracle Patches Over 1,400 Vulnerabilities With Quarterly Security Updates

Oracle has patched more than 1,400 vulnerabilities with its July 2026 Critical Patch Update (CPU), with a vast majority of the flaws likely identified by artificial intelligence.

According to Oracle, the latest quarterly CPU includes 1,449 security patches, addressing 1,434 unique CVEs across 334 products.

Vulnerabilities have been patched in products such as Database Server, APEX, Autonomous Health Framework, Essbase, Global Lifecycle Management, GoldenGate, NoSQL Database, Spatial Studio, SQL Developer, TimesTen In-Memory Database, Application Testing Suite, Commerce, Communications, Construction and Engineering, and E-Business Suite.

Security fixes are also available for Enterprise Manager, Financial Services Applications, Food and Beverage Applications, Fusion Middleware, Analytics, HealthCare Applications, Hospitality Applications, Java SE, JD Edwards, MySQL, PeopleSoft, Retail Applications, Siebel CRM, Supply Chain, Systems, Utilities Applications, and Virtualization.

Roughly 600 of the patches are for vulnerabilities that can be exploited remotely without authentication. Hundreds of security holes have been assigned a critical severity rating.

The highest numbers of vulnerabilities were patched in E-Business Suite (410), Fusion Middleware (355), Communications (168), and PeopleSoft (84).

Advertisement. Scroll to continue reading.

Considering that external researchers have only been credited for discovering a few dozen vulnerabilities, a vast majority of the newly patched flaws were found internally, likely with the aid of AI.

Oracle revealed earlier this year that it has access to top-tier AI systems, including Anthropic’s Claude Mythos and OpenAI’s most capable models, and is using them to speed up and sharpen vulnerability discovery and patching.

The company said it’s applying this AI-driven vulnerability work across its own software and services, Oracle Health, and the open source components it develops and relies on.

Organizations must install the latest patches as soon as possible, as threat actors often exploit Oracle product vulnerabilities in their attacks. Examples include the exploitation of a PeopleSoft zero-day and a recently patched EBS vulnerability.

https://www.securityweek.com/oracle-patches-over-1400-vulnerabilities-with-quarterly-security-updates/

Meta Paid $78,000 Bounty for Vulnerability Exposing Customer Support Data

A security researcher says he has received a significant bug bounty from Meta after discovering a critical vulnerability that exposed customer support data.

The vulnerability was discovered and reported to Meta in January 2026 by independent researcher Rony K Roy. The initial report to the social media giant described a security hole of limited severity, but further analysis revealed that the flaw’s impact was much higher than initially believed.

According to Roy, Meta rolled out patches in April and had not found any evidence of malicious exploitation.

The researcher disclosed his findings last week and told SecurityWeek that he received a $78,000 bug bounty from Meta.

Meta has not responded to SecurityWeek’s request to confirm Roy’s claims, but he is indeed listed as one of the top researchers on the company’s bug bounty leaderboard for 2026.

Roy initially believed he had identified an authorization issue in Meta Horizon Managed Solutions, an enterprise platform for managing Meta Quest devices and users. It turned out to be a broader issue affecting Meta’s backend support infrastructure.

Advertisement. Scroll to continue reading.

The researcher’s analysis led to the discovery of a vulnerability involving missing authorization, broken access control, and insecure direct object reference (IDOR) issues.

When chained, these flaws could have been exploited to enumerate Meta support case numbers and obtain support requests.

According to Roy, an attacker could have exploited the vulnerability to obtain email and chat conversations between users and Meta support, support case details, files submitted to the company via support requests, and personal and contact information shared by users with Meta support.

In addition, an attacker could have created support requests on behalf of organizations that use Meta Horizon Managed Solutions, modified support workflows (including changing case status), and added unauthorized subscribers to support cases.

https://www.securityweek.com/meta-pays-78000-bounty-for-vulnerability-exposing-customer-support-data/

SonicWall Zero-Days Exploited to Deliver Custom Malware for Weeks Before Patch

Two recently patched SonicWall appliance zero-days were exploited by threat actors for weeks before patches were released, according to cybersecurity firm Volexity.

SonicWall released a public advisory for the vulnerabilities on July 14, informing customers that CVE-2026-15409 and CVE-2026-15410 had been exploited in the wild.

Remote, unauthenticated attackers can exploit the flaws to hack SMA1000 secure remote access appliances. SonicWall has made available hotfix releases to address the security holes.

Volexity, which assisted the vendor’s investigation into the attacks, attributed the exploitation of the zero-days to a threat actor it tracks as UTA0533.

The security firm believes exploitation started as early as June 22.

The company on Friday shared IoCs and other technical details related to the attacks, but it has not linked UTA0533 to any known threat actor and the group’s motivation remains unclear. However, based on Volexity’s description, the attack appears more consistent with state-sponsored APT activity rather than a profit-driven cybercrime operation.

Advertisement. Scroll to continue reading.

Once the attackers compromised the targeted SonicWall appliances, they deployed custom malware named KnuckleBall, which injected two other tools into legitimate processes: a tailored Java webshell named OrangeTail, and an open source proxy named Suo5.

“With root access, the threat actor could access stored or cached credentials, capture network traffic, and potentially intercept credentials processed by the appliances,” Volexity said.

The security firm added, “Although UTA0533 demonstrated significant capability in compromising the SonicWall appliances, available evidence suggests the threat actor was less successful moving laterally or gaining access to other systems.”

CISA has added CVE-2026-15409 and CVE-2026-15410 to its KEV catalog, which currently includes 17 flaws affecting SonicWall products.

https://www.securityweek.com/sonicwall-zero-days-exploited-to-deliver-custom-malware-for-weeks-before-patch/

OpenSSL Silently Fixes ‘HollowByte’ DoS Vulnerability

A vulnerability in OpenSSL could allow attackers to cause a server’s memory to be exhausted before any security handshake, Okta’s red team discovered.

Referred to as HollowByte, the denial-of-service (DoS) bug could be triggered via a malicious payload of only 11 bytes that declares a larger incoming message body to trigger a buffer pre-allocation that is not immediately freed.

HollowByte existed because older OpenSSL iterations pre-allocated receive buffer sizes based on the incoming message body length declared in the handshake message’s 4-byte header.

The pre-allocation occurred before any data arrived, and an attacker could send an 11-byte payload to trigger an unvalidated buffer allocation of up to 131 KB.

“The worker thread then blocks, waiting indefinitely for data that will never arrive,” Okta explains.

Additionally, because the GNU C Library (glibc) retains small-to-medium memory allocations for potential reuse and does not immediately return them to the OS when a connection drops, although OpenSSL frees the buffer, multiple successive payloads could be sent to exhaust the server’s memory.

Advertisement. Scroll to continue reading.

“By launching waves of connections with randomized claimed sizes, an attacker prevents the allocator from reusing those freed chunks,” Okta explains.

“Even after the attacker disconnects, the server remains permanently bloated. The only way to reclaim that memory is to terminate the process,” it adds.

In real-world testing, a 1 GB RAM system became unresponsive after 547 MB of memory was fragmented and frozen.

On a 16 GB RAM system, “the attack successfully locked up 25% of the system’s total memory while staying safely under the connection ceiling, meaning standard connection-limiting defenses won’t stop it,” Okta says.

Apache, NGINX, Node.js, Python, Ruby, PHP, MySQL, PostgreSQL, and other types of applications, servers, runtimes, and databases that use OpenSSL are impacted unless they upgrade to a patched version of the open source library.

Patches for HollowByte were silently included in OpenSSL version 4.0.1 and silently backported to versions 3.6.3, 3.5.7, 3.4.6, and 3.0.21. Now, the library increases the buffer size as bytes actually land and no longer trusts the handshake header for buffer growth.

https://www.securityweek.com/openssl-silently-fixes-hollowbyte-dos-vulnerability/