CVE-2026-78006-POC

POC for CVE-2026-78006 The Events Calendar <= 6.17.4 - Unauthenticated PHP Object Injection to Remote Code Execution

Under the documented conditions, an unauthenticated attacker can deliver crafted block markup through an event comment and reach the vulnerable deserialization path before comment moderation occurs.

Vulnerability Summary

The vulnerability exists because the plugin's protection around widget instances is insufficient.

The vulnerable flow can be summarized as:

Affected Plugin

Plugin: The Events Calendar

Vulnerability: Unauthenticated PHP Object Injection leading to Remote Code Execution

Affected versions: All versions up to and including 6.17.4, according to the Wordfence advisory.

[!IMPORTANT] The research PoC currently published with this repository identifies itself internally as targeting <= 6.17.2.

The version range stated above follows the Wordfence advisory (<= 6.17.4). Always verify the exact vulnerable/fixed version against the vendor advisory before testing a deployment.

Root Cause

The vulnerable behavior is associated with the interaction between the widget safety check and PHP's object deserialization behavior.

The key functions involved are:

The security check is insufficient because PHP can invoke magic methods during its parsing/deserialization behavior before the intended safety validation provides effective protection.

The chain also relies on the plugin generating a valid integrity value for the supplied widget instance.

Why Authentication Is Not Required

One of the most important characteristics of this vulnerability is that the attacker does not need an existing WordPress account.

The attack path abuses the way WordPress exposes a user's own pending comment through a moderation-hash URL.

The relevant conditions are:

After submitting a comment, WordPress can provide an unauthenticated moderation-hash URL that allows the commenter to view their own pending comment.

This creates an unauthenticated delivery mechanism for the crafted block markup.

Technical Explanation

1. Comment Submission

The attacker submits a comment associated with an event.

The comment does not need to be approved.

The important property is that WordPress can expose the comment through the moderation-hash mechanism.

2. Moderation-Hash Access

WordPress provides the commenter with a URL that allows the commenter to view their own pending comment.

This means the attacker can reach the vulnerable rendering path without waiting for moderation.

Conceptually:

3. Event Rendering

The Events Calendar's V2 single-event template processes the event content and comment-related HTML.

The relevant WordPress processing path eventually reaches:

This is important because block markup embedded in the rendered content is interpreted as WordPress block data.

4. Crafted Block Data

The PoC constructs a legacy-widget block containing a serialized widget instance.

The research implementation builds the block using an encoded serialized instance and an integrity attribute.

The vulnerable path ultimately processes this data as a widget instance.

5. Integrity Bypass

The plugin's enable_rendering_widget_copied() behavior can be abused to produce a valid integrity attribute for the attacker-controlled widget data.

This allows the malicious widget instance to pass the expected integrity check and reach the vulnerable processing path.

6. Unsafe Object Handling

The vulnerable is_safe_widget_instance() protection is insufficient against the object supplied through the crafted widget instance.

PHP's object handling behavior can invoke magic methods during the deserialization process.

The result is an exploitable PHP Object Injection primitive.

7. Gadget Chain

The research PoC constructs WordPress / The Events Calendar object structures that provide callable behavior during deserialization.

The PoC uses callback-oriented objects and serialized class structures to construct the research payload.

8. Code Execution

The final impact is Remote Code Execution.

The PoC contains a research webshell stage and administrator-creation logic.

For safe vulnerability verification, the important security boundary is already demonstrated by successful execution of the vulnerable deserialization chain.

Why the Vulnerability Is Critical

The combination of:

creates a high-impact attack path.

An attacker does not need:

• An administrator account
• A valid WordPress password
• Password cracking
• Existing privileged credentials

The main environmental prerequisite is that the vulnerable event/comment rendering path is reachable.

Research PoC

The repository contains a Python-based research implementation.

The uploaded PoC is an asynchronous runner around the original research logic.

It uses:

The implementation performs the vulnerability chain through staged payload delivery and verification.

The PoC source describes its architecture as:

PoC Capabilities

The research implementation includes functionality for:

• Target processing
• Event discovery
• Comment delivery
• Serialized PHP object construction
• Widget block construction
• Vulnerability verification
• Environment information collection
• Stage-based payload delivery
• Administrator creation
• Webshell deployment
• Result collection
• Concurrent processing of multiple URLs

The PoC also contains platform-aware checks for Windows and Unix-like environments.

Single Target

The research tool can be used against an individual authorized WordPress installation.

Conceptually:

A single-target workflow is useful for:

• Local labs
• Staging systems
• CVE reproduction
• Vendor testing
• Authorized penetration testing
• Security research

URL List

The asynchronous runner also supports a list of URLs.

The input format is:

Example:

Blank lines and comments can be ignored.

The runner loads the targets and processes them concurrently using the configured thread/concurrency count.

Concurrent Processing

The PoC supports concurrent processing of multiple targets.

Conceptually:

The implementation uses an asynchronous semaphore to control the concurrency level.

The default configured concurrency in the runner is 20.

Output

The asynchronous runner can create two result files:

shells.txt contains discovered uploaded shell URLs.

admins.txt contains administrator result information in the form:

[!WARNING] These files can contain extremely sensitive credentials and post-exploitation artifacts.

Never publish generated result files to GitHub.

For public vulnerability research, keep these files outside the Git repository and add them to .gitignore.

Recommended .gitignore

Use the minimum level of interaction required to prove the finding.

Important Prerequisites

The Wordfence advisory identifies the following important condition:

The attack relies on the ability of an unauthenticated commenter to view their own pending comment through the WordPress moderation-hash URL.

If comments are disabled or the relevant event comment path is not available, the documented unauthenticated delivery mechanism may not be reachable.

Platform Considerations

The PoC contains environment-detection functionality.

The research code attempts to identify information such as:

These values are useful for controlled research and understanding the impact of successful code execution.

Payload Architecture

The serialized payload contains multiple nested PHP objects.

The research implementation builds structures associated with:

The serialized structures are then embedded into a WordPress legacy widget block.

Conceptually:

Stage 1

The research PoC's first stage is designed to verify that the injected object graph reaches the intended execution path.

The stage contains multiple controlled callbacks used to determine whether code execution or environment disclosure occurred.

The implementation includes research checks such as:

Stage 2

If the initial stage does not directly establish the required persistent artifact location, the PoC contains a second-stage mechanism that attempts alternative locations.

The research implementation specifically considers WordPress upload locations and document-root-related paths.

Administrator Stage

The PoC also contains administrator creation functionality.

The research implementation can construct a WordPress administrator through the vulnerable execution path.

This demonstrates that successful exploitation can result in both:

Administrator credentials generated during research should never be committed to source control.

Webshell Stage

The PoC contains a webshell stage intended for controlled research.

The webshell is packaged as a WordPress plugin ZIP and deployed through an authenticated WordPress administrator session established by the chain.

The research implementation uses a secret token to gate shell requests.

[!CAUTION] The webshell is an exploitation artifact.

Use it only in an isolated laboratory or during an explicitly authorized penetration test, and remove it immediately after testing.

Verification

Successful vulnerability validation can be based on evidence such as:

For responsible disclosure, collect only the minimum evidence required.

Impact

Successful exploitation may allow an unauthenticated attacker to:

• Execute arbitrary PHP code
• Execute commands in the context of the web server
• Read sensitive application information
• Access environment information
• Modify WordPress files
• Create administrator accounts
• Install malicious plugins
• Establish persistence
• Potentially compromise the underlying server

The ultimate impact depends on the privileges of the PHP process and the hosting environment.

Detection

Defenders should monitor for unusual activity involving:

• Event comment submissions
• Pending comments followed by moderation-hash access
• Suspicious block markup
• Legacy widget blocks
• Unexpected widget instance data
• Unexpected serialized PHP objects
• PHP execution triggered during event rendering
• Unexpected plugin installations
• New administrator accounts
• Unexpected PHP files
• Suspicious files under wp-content/uploads/

A compromise investigation should correlate:

Indicators of Compromise

Potential indicators include:

Because individual indicators can have legitimate explanations, they should be investigated in context.

Mitigation

The primary mitigation is to update The Events Calendar to a fixed version provided by the vendor.

Until the plugin is updated, defenders should consider:

• Disabling comments where operationally acceptable
• Restricting public event comments
• Monitoring event comment traffic
• Reviewing recently created administrator accounts
• Monitoring plugin installation activity
• Performing file-integrity checks
• Reviewing web-server logs
• Reviewing WordPress logs

If compromise is suspected, treat the system as potentially compromised rather than merely vulnerable.

Incident Response

If exploitation is suspected:

1. Preserve relevant logs.
2. Identify suspicious requests.
3. Review administrator accounts.
4. Review installed plugins.
5. Inspect recently modified PHP files.
6. Inspect wp-content/uploads/.
7. Rotate WordPress credentials.
8. Rotate hosting/server credentials where appropriate.
9. Remove unauthorized persistence.
10. Restore trusted application files when necessary.
11. Upgrade the vulnerable plugin.
12. Continue monitoring for re-entry.

Responsible Disclosure

When reporting this vulnerability or derivative research:

• Clearly identify the affected plugin.
• Include the affected version.
• Include the fixed version when confirmed.
• Explain the unauthenticated attack path.
• Document the required prerequisites.
• Provide reproducible evidence in a controlled environment.
• Avoid publishing victim data.
• Never publish generated administrator credentials.
• Never publish live webshell URLs.

Research Limitations

A vulnerable plugin version alone does not guarantee successful exploitation.

The attack path can be affected by:

• WordPress configuration
• Comment settings
• Event visibility
• Template configuration
• Security plugins
• Web Application Firewalls
• Reverse proxies
• PHP configuration
• Hosting permissions
• Object caching
• Network filtering

Therefore, version fingerprinting should be treated as an initial indicator rather than definitive proof of exploitability.

Repository Safety

Do not commit:

Use synthetic laboratory targets when creating screenshots, demonstrations, or documentation.

Recommended Repository Structure

Keep runtime artifacts outside the repository.

Technical Summary

Severity

Impact: Remote Code Execution

Authentication: Not required

Attack Vector: Remote

Primary Component: The Events Calendar

Primary Vulnerable Functions:

Delivery Mechanism:

Key Takeaway

The important aspect of this vulnerability is not simply that the plugin uses PHP serialization.

The complete unauthenticated attack path is enabled by the combination of:

This combination creates an unauthenticated path to PHP Object Injection and Remote Code Execution.

Credits

Vulnerability details and affected-version information:

Wordfence Threat Intelligence

Research PoC:

The Events Calendar PHP Object Injection / RCE research implementation

References

• Wordfence Threat Intelligence — The Events Calendar PHP Object Injection / RCE vulnerability
• The Events Calendar
• WordPress Core
• WordPress Comments
• WordPress Block Editor
• WordPress do_blocks()
• PHP Object Serialization / Deserialization

Disclaimer

This repository contains security research concerning a remote-code- execution vulnerability affecting a WordPress plugin.

The PoC is provided for:

• Security research
• Defensive validation
• Authorized penetration testing
• Controlled laboratory reproduction
• Education

Only test systems that you own or have explicit written authorization to assess.

The authors are not responsible for unauthorized use of this research.

Keywords