## https://sploitus.com/exploit?id=C6D57857-780F-507B-BE68-A4C3C17A833E
# CVE-2026-78006-POC
POC for CVE-2026-78006 The Events Calendar <= 6.17.4 - Unauthenticated PHP Object Injection to Remote Code Execution
#CONTACT **telegram** for any ask : **@soldout0O**
### 💙 Support the Project
If you appreciate my work, consider supporting the project via **USDT (TRC20):** `TQBA72kakjCZLnJt8fJYcD7dyQCEpzNtVN`
# The Events Calendar — Unauthenticated PHP Object Injection to RCE
## Security Research PoC
**The Events Calendar** for WordPress contains an unauthenticated PHP
Object Injection vulnerability that can be chained to Remote Code
Execution.
The vulnerable code path involves:
* `is_safe_widget_instance()`
* `enable_rendering_widget_copied()`
* PHP magic-method handling during object deserialization
* `unserialize()`
* The V2 single-event template
* `do_blocks()`
* WordPress comment moderation-hash functionality
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:
```text
Unauthenticated Comment
|
v
Pending Event Comment
|
v
WordPress Moderation-Hash URL
|
v
Unauthenticated Author Can View Own Pending Comment
|
v
V2 Single-Event Template
|
v
do_blocks()
|
v
Injected Block Markup
|
v
enable_rendering_widget_copied()
|
v
Forged Integrity Attribute
|
v
is_safe_widget_instance()
|
v
PHP Magic Methods / Object Deserialization
|
v
unserialize()
|
v
PHP Object Injection
|
v
Remote Code Execution
```
---
# 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 `
> The version range stated above follows the Wordfence advisory
> (` 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:
```text
is_safe_widget_instance()
enable_rendering_widget_copied()
```
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:
```text
Comments enabled
+
Comments visible on events
+
Attacker can submit an event comment
+
V2 single-event template active
```
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:
```text
POST Comment
|
v
Pending Comment
|
v
Moderation Hash
|
v
Unauthenticated Access
```
---
## 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:
```text
do_blocks()
```
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:
```text
Unauthenticated
+
Remote
+
PHP Object Injection
+
RCE
```
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:
```text
Python
aiohttp
rich
```
The implementation performs the vulnerability chain through staged
payload delivery and verification.
The PoC source describes its architecture as:
```text
payload building
|
v
stage 1
|
v
verification
|
v
stage 2
```
---
# 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:
```text
Single URL
|
v
Target Discovery
|
v
Event Discovery
|
v
Comment Delivery
|
v
Vulnerability Trigger
|
v
Verification
```
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:
```text
one URL per line
```
Example:
```text
https://lab-wordpress-01.example
https://lab-wordpress-02.example
https://lab-wordpress-03.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:
```text
URL LIST
|
+-----------+-----------+
| | |
v v v
Worker 1 Worker 2 Worker 3
| | |
v v v
Target Target Target
| | |
+-----------+-----------+
|
v
Results
```
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:
```text
shells.txt
admins.txt
```
`shells.txt` contains discovered uploaded shell URLs.
`admins.txt` contains administrator result information in the form:
```text
url | user | pass
```
> [!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`
```gitignore
# PoC results
shells.txt
admins.txt
# Research Workflow
For responsible vulnerability validation:
```text
START
|
v
Verify plugin version
|
v
Verify prerequisites
|
v
Confirm comments are enabled
|
v
Confirm events expose comments
|
v
Reproduce in a lab
|
v
Confirm vulnerable behavior
|
v
Record evidence and logs
|
v
Stop / disclose
```
Use the minimum level of interaction required to prove the finding.
---
# Important Prerequisites
The Wordfence advisory identifies the following important condition:
```text
Comments must be enabled
and
comments must be visible on events
```
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:
```text
Operating system
Current execution user
Current working directory
Document root
Server software
HTTP host
PHP information
```
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:
```text
Tribe__Utils__Callback
Tribe\Utils\Element_Classes
stdClass
```
The serialized structures are then embedded into a WordPress legacy
widget block.
Conceptually:
```text
PHP Object Graph
|
v
Serialized Object
|
v
Base64 Encoding
|
v
Legacy Widget Block
|
v
WordPress do_blocks()
|
v
The Events Calendar
|
v
Object Deserialization
```
---
# 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:
```text
Current working directory
Execution user
Document root
Server information
PHP information
```
---
# 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:
```text
Remote Code Execution
+
Persistent WordPress Administrator Access
```
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:
```text
Plugin version
+
Reachable event
+
Comment delivery
+
Moderation-hash rendering
+
Vulnerable widget processing
+
Controlled execution evidence
```
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:
```text
Web Server Logs
+
WordPress Logs
+
Database Activity
+
File Integrity
+
Administrator Accounts
```
---
# Indicators of Compromise
Potential indicators include:
```text
Unexpected administrator accounts
Unexpected plugin directories
Unexpected PHP files
Suspicious files in wp-content/uploads/
Unexpected event comments
Abnormal moderation-hash requests
Unexpected widget-related requests
Unexpected PHP execution
```
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:
```text
shells.txt
admins.txt
real target URLs
generated credentials
webshell files
captured phpinfo output
database dumps
server environment information
private test data
```
Use synthetic laboratory targets when creating screenshots,
demonstrations, or documentation.
---
# Recommended Repository Structure
```text
the-events-calendar-poc/
│
├── poc.py
├── README.md
├── LICENSE
├── .gitignore
│
├── screenshots/
│ └── .gitkeep
│
└── docs/
└── research-notes.md
```
Keep runtime artifacts outside the repository.
---
# Technical Summary
```text
The Events Calendar
|
v
V2 Single Event Template
|
v
WordPress do_blocks()
|
v
Legacy Widget Block
|
v
Forged Widget Instance
|
v
Valid Integrity Attribute
|
v
is_safe_widget_instance()
|
v
PHP Object Deserialization
|
v
Magic Method Invocation
|
v
PHP Object Injection
|
v
Remote Code Execution
```
---
# Severity
**Impact:** Remote Code Execution
**Authentication:** Not required
**Attack Vector:** Remote
**Primary Component:** The Events Calendar
**Primary Vulnerable Functions:**
```text
is_safe_widget_instance()
enable_rendering_widget_copied()
```
**Delivery Mechanism:**
```text
Event comments
+
WordPress moderation-hash URL
+
V2 event rendering
```
---
# 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:
```text
Insufficient widget validation
+
PHP magic-method behavior
+
Forged integrity attribute
+
do_blocks()
+
Public event comments
+
Moderation-hash access
```
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
```text
CVE-2026-78006
The Events Calendar
The Events Calendar WordPress
The Events Calendar vulnerability
The Events Calendar RCE
The Events Calendar PHP Object Injection
WordPress
CVE-2026-78006 POC
WordPress Security
WordPress Vulnerability
WordPress RCE
PHP Object Injection
PHP Deserialization
Unauthenticated RCE
Remote Code Execution
CVE
WordPress Plugin Security
WordPress Plugin RCE
is_safe_widget_instance
enable_rendering_widget_copied
do_blocks
WordPress comments
moderation hash
legacy-widget
security research
PoC
Proof of Concept
penetration testing
```