Post cover image

October 1, 2026

🚨 CraftFall Explained | Remote Code Execution & Bug Bounty Automation

One vulnerable CMS endpoint. A dangerous framework behavior. And a remote-code-execution vulnerability that security researchers cannot…

By Pentester Club

11 min read

One vulnerable CMS endpoint. A dangerous framework behavior. And a remote-code-execution vulnerability that security researchers cannot afford to ignore.

Imagine discovering a publicly accessible website running an outdated content management system. You identify its technology, investigate the exposed application endpoints, and discover that a seemingly ordinary asset-processing feature could provide a path to server-side code execution.

This is the kind of security issue that makes vulnerability research interesting.

Today, we're looking at CraftFall, using the public proof-of-concept repository for CVE-2025–32432:

🔗 GitHub Repository: https://github.com/theeomega/CVE-2025-32432-POC

This vulnerability affects Craft CMS and demonstrates how unsafe object creation and framework-level behavior can create a serious remote-code-execution risk.

Embedded content

We'll explore:

  • What Craft CMS is.
  • What CVE-2025–32432 does.
  • Why the asset transformation endpoint matters.
  • How the public PoC is structured.
  • How security researchers can investigate the vulnerability safely.
  • How bug bounty workflows can automate detection and evidence collection.
  • How organizations can detect and remediate potential exploitation.

🔥 1. What Is Craft CMS?

is a flexible content management system used to build websites and digital experiences.

It provides functionality for:

  • Content management.
  • Asset management.
  • Image transformations.
  • Custom fields.
  • Plugins and extensions.
  • User and permission management.
  • Website administration.

Like other complex web applications, Craft CMS depends on frameworks and libraries to process requests, manage objects, and perform application operations.

That dependency chain matters.

A vulnerability in a framework component can sometimes affect the application using it, particularly when the application exposes unsafe functionality through its own endpoints.

This is the background behind CVE-2025–32432.

🚨 2. What Is CVE-2025–32432?

is a critical remote code execution vulnerability affecting Craft CMS.

The vulnerability involves unsafe object handling associated with the Yii framework.

An attacker can potentially abuse the vulnerable asset transformation functionality to trigger server-side code execution without authentication.

The official Craft CMS security advisory explains that the issue was reported on April 7, 2025, and that patched releases were published on April 10, 2025. Craft CMS also reported evidence suggesting exploitation in the wild on April 17, 2025.

Affected versions

Craft CMS branchAffected versionsFirst patched version3.xBefore 3.9.153.9.154.xBefore 4.14.154.14.155.xBefore 5.6.175.6.17

These are the original branch-specific fixes published for this CVE. Administrators should use currently supported, fully updated releases rather than treating those historical minimum versions as a complete security baseline.

Critical vulnerability Pre-authentication RCE

The key security implications include:

  • Remote code execution.
  • Potential server compromise.
  • Exposure of application secrets.
  • Unauthorized access to server-side data.
  • Potential modification of application files.
  • Potential disruption of the hosted service.

🧠 3. Understanding the Root Cause

To understand this vulnerability, we need to look beyond the fact that a particular endpoint is exposed.

The deeper issue concerns how application-controlled input reaches framework functionality.

A simplified application flow looks like this:

HTTP Request
                      |
                      v
              Craft CMS Controller
                      |
                      v
             Asset Transform Logic
                      |
                      v
              Object Construction
                      |
                      v
             Framework Functionality
                      |
                      v
              Unsafe Object Handling

The security problem occurs when externally influenced data reaches sensitive object-handling functionality without sufficient validation.

This can create an opportunity for an attacker to influence application behavior in ways the developer never intended.

Why is this dangerous?

Applications frequently use objects to represent:

  • Services.
  • Files.
  • Components.
  • Configuration.
  • Database connections.
  • Application functionality.

When untrusted input can influence object creation, the application must enforce strict restrictions over which objects and behaviors can be accessed.

Otherwise, a feature intended for a normal application operation can become an unexpected execution pathway.

🔍 4. Why the Asset Transformation Endpoint Matters

The vulnerability is associated with Craft CMS's asset transformation functionality.

The relevant endpoint is:

/actions/assets/generate-transform

Craft CMS uses asset transformations to generate image variations for websites.

For example:

Original Image
      |
      v
Asset Processing
      |
      v
Image Transformation
      |
      v
Generated Image

This is normal application functionality.

However, the official advisory identifies suspicious POST requests to this endpoint containing the string __class as an indicator that a site may have been scanned for CVE-2025-32432.

The important distinction:

An asset transformation feature should process valid image-related data — not allow an external request to influence dangerous framework object construction.

This is why input validation and safe object instantiation are fundamental application-security requirements.

🧩 5. Understanding the Public CraftFall PoC

The repository supplied for this article is:

theeomega/CVE-2025–32432-POC

It contains a Python-based, single-target proof of concept.

According to its README, the project separates vulnerability confirmation from optional command execution. It also describes a two-stage process involving the asset transformation endpoint and PHP session-file handling.

Let's understand the architecture without reproducing the exploit payloads.

Stage A — Application preparation and request handling

The PoC establishes the necessary request context and examines the application's response behavior.

At a conceptual level:

Authorized Test Environment
          |
          v
     HTTP Request
          |
          v
     Craft CMS
          |
          v
    Asset Endpoint

The purpose is to determine whether the vulnerable application behavior is present.

Stage B — Vulnerability confirmation

The repository describes using a PHP information-related gadget as a confirmation mechanism.

This is intended to establish whether the vulnerable code path is being reached.

The important research distinction is between:

  • An endpoint responding.
  • A suspicious request being processed.
  • A vulnerability being confirmed.
  • Actual impact being demonstrated.

These are not interchangeable.

Stage C — Optional impact demonstration

The repository also documents a second-stage mechanism involving session-file handling and an application component that can include the affected file.

This is where the potential impact moves from vulnerability confirmation to code execution.

For responsible research, this stage should not be reproduced against production systems. A non-destructive validation result, supported by reliable evidence, is preferable whenever it is sufficient to establish the finding.

The repository documents both stages in its README.

🔬 6. What Makes This PoC Interesting?

There are several aspects worth understanding from a penetration-testing perspective.

Single-target design

The repository describes itself as a single-target PoC.

That matters because vulnerability validation should be deliberate.

A researcher should know exactly which application is being assessed and should not accidentally turn a proof of concept into uncontrolled scanning.

Separate confirmation and impact stages

Separating vulnerability confirmation from optional impact demonstration is a useful research design principle.

A security assessment should answer:

  1. Is the vulnerable condition present?
  2. Can it be demonstrated safely?
  3. What impact is supported by the evidence?
  4. What is the minimum additional testing needed?

Handling false negatives

The repository also discusses a potential false-negative situation involving ordinary asset transformation requests returning an HTTP 404 response while the actual PoC follows a different request path.

This is an important lesson:

An HTTP status code alone does not always establish whether a vulnerability exists.

A 404, 403, or 500 response must be interpreted in the context of the application behavior and available evidence.

🧪 7. Building a Safe Craft CMS Research Lab

If you want to understand this vulnerability hands-on, use a dedicated isolated environment.

A suitable architecture is:

Research Workstation
                      |
                      |
               Isolated Network
                      |
                      v
              ┌───────────────┐
              │   Craft CMS   │
              │   Test VM     │
              └───────┬───────┘
                      |
                      v
              ┌───────────────┐
              │ Test Database │
              └───────────────┘

Recommended precautions:

  • Use a disposable virtual machine.
  • Use a deliberately vulnerable test release.
  • Keep the VM isolated from production networks.
  • Use synthetic data.
  • Avoid real customer information.
  • Take a snapshot before testing.
  • Restrict outbound network connectivity.
  • Monitor application and web-server logs.
  • Destroy or restore the environment after testing.

The goal is to reproduce the security behavior without putting a real organization at risk.

🤖 8. Bug Bounty Automation: Where Does It Fit?

Now let's move beyond the individual PoC.

One of the most useful applications of this research is building a repeatable vulnerability-intelligence workflow.

Imagine a bug bounty platform that needs to identify potentially vulnerable Craft CMS deployments across an explicitly authorized asset inventory.

A useful architecture could look like this:

Authorized Asset Inventory
                        |
                        v
                Scope Validation
                        |
                        v
                Technology Detection
                        |
                        v
                 Craft CMS Detection
                        |
                        v
                Version Identification
                        |
                        v
                Vulnerability Matching
                        |
                        v
                Evidence Collection
                        |
                        v
                  Human Review
                        |
                        v
                 Security Report

The key is to distinguish technology detection from vulnerability confirmation.

A website using Craft CMS is not automatically vulnerable.

A version that appears outdated is not automatically proof of successful exploitation.

The automation must preserve those distinctions.

🔎 9. Step One: Scope Validation

Before any testing begins, the platform must determine whether the target is authorized.

For example:

Program Scope
example-lab.com
*.example-lab.com
10.20.0.0/24

The scope-validation component should check:

  • Exact hostnames.
  • Wildcard restrictions.
  • IP address ranges.
  • Excluded systems.
  • Testing restrictions.
  • Rate limits.
  • Program-specific rules.

A useful decision flow:

Target Input
                  |
                  v
             Scope Check
                  |
             ┌────┴────┐
             |         |
           In Scope  Out of Scope
             |         |
             v         v
         Continue     Stop

This should be enforced by application logic, not left solely to an AI model.

🧠 10. Step Two: Technology Fingerprinting

The next step is identifying whether the authorized application is running Craft CMS.

Technology fingerprinting may use:

  • HTTP response characteristics.
  • Public application metadata.
  • HTML and asset references.
  • Known application paths.
  • Technology-detection tools.
  • Authorized version disclosures.

A conceptual result might look like:

{
  "host": "example-lab.com",
  "technology": "Craft CMS",
  "detection": "fingerprint",
  "version": "unknown",
  "confidence": "medium",
  "status": "requires_review"
}

Notice that the version is unknown.

That is better than inventing a version based on incomplete evidence.

📊 11. Step Three: Vulnerability Intelligence Matching

Once Craft CMS has been identified, the automation can consult vulnerability intelligence sources.

For CVE-2025–32432, the relevant version ranges are:

Craft CMS 3.x → before 3.9.15
Craft CMS 4.x → before 4.14.15
Craft CMS 5.x → before 5.6.17

These are the historical affected ranges for this vulnerability.

A version-matching engine can compare observed version information with the published advisory.

Example:

Detected Product
       |
       v
   Craft CMS
       |
       v
  Version Found?
       |
   ┌───┴────┐
   |        |
  Yes       No
   |        |
   v        v
Compare   Mark as
Versions  Unknown
   |
   v
Potentially Affected?
   |
   v
Require Validation

The automation should preserve the source of the version information and its confidence level.

🔥 12. Step Four: Evidence Collection

This is where many automated bug bounty systems make mistakes.

They detect a technology, match it to a CVE, and immediately generate a critical finding.

That's not a professional vulnerability-validation process.

A better system collects:

EvidencePurposeHTTP responseRecord application behaviorTechnology fingerprintSupport product identificationVersion evidenceDetermine affected-version applicabilityAdvisory referenceDocument the vulnerabilitySafe validation resultSupport the findingTimestampPreserve testing historyScope recordDemonstrate authorization

A finding should not be marked confirmed merely because a scanner recognizes a product.

🧪 13. Step Five: Safe Validation

A bug bounty workflow should prioritize low-impact validation.

For this vulnerability, that means:

  • Confirm the target is in scope.
  • Identify the Craft CMS deployment.
  • Determine whether version evidence indicates exposure.
  • Review the relevant official advisory.
  • Use an approved, non-destructive validation method where available.
  • Avoid unnecessary command execution.
  • Stop when sufficient evidence has been collected.

The important question is:

Can the vulnerability be established without causing additional impact to the target?

For a critical pre-authentication RCE, unnecessary exploitation is difficult to justify when version and controlled validation evidence already establish the security issue.

🤖 14. AI-Assisted Vulnerability Analysis

An AI assistant can make this workflow more useful by interpreting collected evidence.

For example:

Input:
Craft CMS detected.
Version information is incomplete.
Asset transformation endpoint identified.
AI Analysis:
- Product identification requires verification.
- Version applicability is unknown.
- CVE-2025-32432 may be relevant.
- No confirmed exploitation evidence is available.
Recommended Action:
Collect reliable version evidence and review
the official vendor advisory.

This is a much more responsible use of AI than allowing a model to execute arbitrary exploit commands.

AI can help with:

  • Technology identification analysis.
  • Advisory summarization.
  • Version comparison.
  • Evidence organization.
  • False-positive reduction.
  • CWE mapping.
  • Report drafting.
  • Remediation recommendations.

Human review remains necessary for the final security determination.

🧰 15. A Practical Automation Architecture

For a Pentester Club-style bug bounty platform, the architecture could be:

Pentester Club
                       |
                       v
               Authorized Programs
                       |
                       v
                 Scope Engine
                       |
                       v
                Reconnaissance
                       |
                       v
              Technology Detection
                       |
                       v
              Vulnerability Database
                       |
                       v
                CVE Correlation
                       |
                       v
              Evidence Management
                       |
                       v
                 AI Assistant
                       |
                       v
                Human Validation
                       |
                       v
                Report Generator

Potential components include:

ComponentResponsibilityScope engineEnforce program boundariesRecon moduleCollect authorized asset informationFingerprintingIdentify application technologiesCVE intelligenceMatch products and versionsEvidence managerPreserve validation artifactsAI assistantAnalyze and summarize findingsReport engineGenerate professional reportsAudit systemRecord tester and tool activity

This design makes vulnerability research more repeatable and easier to audit.

🚨 16. Detection: How Defenders Can Identify Attempts

The official Craft CMS advisory provides a particularly useful detection clue.

Craft CMS administrators should review firewall and web-server logs for suspicious POST requests to:

/actions/assets/generate-transform

especially when the request body contains:

__class

Craft CMS explicitly states that this can indicate the website has been scanned for CVE-2025–32432.

However, finding such a request does not prove successful exploitation.

Defensive investigation checklist

Review:

  • Web-server access logs.
  • Application logs.
  • Requests to asset transformation routes.
  • Unusual POST request bodies.
  • Unexpected PHP files.
  • Asset upload directories.
  • Public HTML directories.
  • PHP session storage.
  • Unexpected file modifications.
  • Unusual processes running under the web-server account.

Correlate timestamps across different log sources.

A single suspicious request is an indicator for investigation, not a complete incident conclusion.

🛡️ 17. How to Remediate CVE-2025–32432

The primary remediation is to upgrade Craft CMS.

The original patched releases were:

Craft CMS 3.9.15
Craft CMS 4.14.15
Craft CMS 5.6.17

Use a currently supported and updated release appropriate to your deployment.

Craft CMS also documented a temporary security-patches library and firewall filtering as mitigation options for organizations that could not immediately upgrade. These should not be treated as substitutes for applying the permanent fix.

If exploitation is suspected

Craft CMS recommends a more extensive response:

  • Restrict public access to the affected site.
  • Investigate and remove malicious files.
  • Rebuild from trusted application code where appropriate.
  • Update Craft CMS and its plugins.
  • Refresh the Craft security key.
  • Rotate database credentials.
  • Rotate other potentially exposed secrets.
  • Consider requiring password resets.
  • Re-enable access only after the investigation and remediation are complete.

These steps are important because removing a visible malicious file does not necessarily remove every persistence mechanism or exposed credential.

📋 18. Writing a Professional Bug Bounty Report

A useful report should communicate the vulnerability without exaggerating what was actually demonstrated.

Here's a report structure:

Vulnerability Title

Pre-Authentication Remote Code Execution in Craft CMS — CVE-2025–32432

Affected Asset

Target:
[Authorized target]
Technology:
Craft CMS
Observed Version:
[Evidence-supported version]
Endpoint:
Asset transformation functionality

Description

Craft CMS versions within the affected ranges for CVE-2025–32432 are vulnerable to remote code execution through unsafe object handling associated with asset transformation functionality.

The vulnerability may allow an unauthenticated remote attacker to execute code on the server.

Impact

Successful exploitation could compromise the confidentiality, integrity, and availability of the affected application and potentially expose sensitive server-side information.

Evidence

Include:

  • Authorized target information.
  • Product and version evidence.
  • Relevant HTTP observations.
  • Safe validation results.
  • Official advisory references.
  • Timestamps.
  • Screenshots or sanitized logs.

Remediation

Upgrade to a currently supported Craft CMS release containing the security fix.

References

  • Craft CMS official advisory.
  • CVE record.
  • GitHub security advisory.

A good report explains what was observed, what was confirmed, and what remains unverified.

🧠 19. Lessons for Security Researchers

CVE-2025–32432 provides several important lessons.

Lesson 1: Framework security matters.

An application can expose dangerous behavior through an underlying framework even when the application feature itself appears ordinary.

Lesson 2: Object construction requires strict validation.

Externally controlled input should never be allowed to instantiate arbitrary application objects.

Lesson 3: HTTP status codes are not vulnerability verdicts.

A 404 response alone does not establish that a vulnerable code path is absent.

Lesson 4: Confirmation and exploitation are different activities.

A researcher should collect the minimum evidence necessary to establish impact.

Lesson 5: Automation needs scope enforcement.

A bug bounty scanner must respect the program's authorization boundaries.

Lesson 6: Detection and remediation matter as much as discovery.

Finding an RCE is only one part of the security lifecycle. Organizations also need to investigate, patch, rotate secrets, and verify recovery.

🔥 20. Turning CraftFall Research into a Security Platform

This vulnerability also demonstrates an opportunity for cybersecurity platform developers.

Imagine an automated system that:

  1. Imports an authorized bug bounty scope.
  2. Identifies Craft CMS deployments.
  3. Collects reliable version information.
  4. Matches the application against CVE intelligence.
  5. Identifies potentially affected assets.
  6. Collects safe validation evidence.
  7. Assigns a confidence level.
  8. Sends the result for human review.
  9. Generates a structured report.
  10. Tracks remediation status.

The resulting system is not simply an exploit launcher.

It is a vulnerability-management and security-research platform.

That's a more sustainable approach to bug bounty automation.

🏁 Final Thoughts

CVE-2025–32432 is an important example of how a seemingly ordinary application feature can expose a serious security weakness.

The Craft CMS asset transformation functionality became associated with a critical remote-code-execution vulnerability because of unsafe framework-level object handling.

The public CraftFall PoC provides a way to study the vulnerability's structure, while the official Craft CMS advisory provides the affected versions, historical exploitation context, and remediation guidance.

But the biggest takeaway goes beyond this individual CVE.

Modern bug bounty research should combine reconnaissance, vulnerability intelligence, evidence collection, safe validation, and professional reporting.

Automation can make that process faster.

AI can make the analysis more accessible.

But authorization, evidence, and human judgment must remain at the center.

Find the vulnerability. Understand the root cause. Validate responsibly. Report with evidence. Help organizations become more secure.

🔗 References & Research Resources