Security Posture Report - July 2026

Attack chain

1. Initial access: Attackers scan for publicly exposed XXL-JOB assets. They gain the ability to dispatch tasks either by logging in to the scheduler's admin console with a weak password, such as admin/123456, or by directly accessing an executor's unauthorized API.

2. Execution: Attackers use scheduled tasks to deliver and run scripts. The executor then runs these scripts on the target server to execute arbitrary system commands.

3. Payload delivery: Attackers implant malicious mining programs, fileless backdoors, and DDoS trojans to consume computing resources and enroll the host in a botnet.

4. Defense evasion: After execution, they clear the scheduled task logs to hide evidence of the intrusion, which complicates forensic investigation.

Affected versions: All versions are affected when the executor's accessToken is empty or uses the default value, and both the scheduler and executor are exposed to the public internet. Scheduler versions 3.3.2 and earlier also have a hardcoded default accessToken issue (CVE-2026-7306). | Secure versions: 3.4.2 and later

Security recommendations

If you are using XXL-JOB, perform the following checks and take immediate action:

1. Reduce the publicly exposed attack surface (Recommended): Do not expose the scheduler xxl-job-admin and executor ports (default 9999) to the public internet. Use a security group to create an IP address allowlist that only permits access from trusted sources like schedulers and bastion hosts.

2. Rotate the accessToken and remove weak passwords: Do not leave the xxl.job.accessToken empty or use the default value default_token. Change it to a strong, random value and apply it to both the scheduler and all executors. Reset weak passwords for default accounts, such as admin/123456.

3. Upgrade to a secure version: Upgrade to version 3.4.2 or later. You can download it from https://github.com/xuxueli/xxl-job/releases.

Note: Before upgrading or changing configurations, create backups and verify business connectivity. The accessToken must be updated on both the scheduler and executors simultaneously to avoid disrupting the task scheduling process.

If you receive a related security alert, follow the provided guidance to remediate the issue immediately. If you have any questions, submit a security ticket for assistance.

Gitea remote code execution vulnerability (CVE-2026-60004)

Gitea is a lightweight, self-hosted Git service that is easy to deploy and often used by teams on private networks. In July 2026, a code injection vulnerability was disclosed. An attacker with repository write permissions, which can be obtained by self-registering on instances with open registration, can use the diffpatch API to implant and execute arbitrary code on the server. This allows them to take control of the server with the privileges of the Gitea service account and steal sensitive information like configurations and credentials. We have observed threat actors exploiting this vulnerability to install malicious mining programs. A public proof-of-concept (PoC) and a low barrier to exploitation make this a high-risk vulnerability. We strongly recommend addressing this issue immediately.

Affected versions: 1.17 to 1.27.0 (including all branches from 1.23 to 1.26) | Secure versions: 1.27.1 and later

If you are using an affected version of Gitea, perform the following checks and take immediate action:

1. Upgrade to a secure version (Recommended): Upgrade to version 1.27.1 or later. This is the only complete fix, which changes the temporary clone from a bare to a non-bare repository. Gitea Cloud instances have been automatically upgraded.

2. Restrict accounts and public exposure: Disable open registration on internet-facing instances (service.DISABLE_REGISTRATION = true). Audit and revoke unnecessary repository write permissions. Note that disabling registration alone does not fix the vulnerability and does not prevent existing users with write access from exploiting it.

3. Temporarily block the high-risk API endpoint: Until you can apply a patch, use a reverse proxy or WAF to block requests to the /api/v1/repos/*/diffpatch path. If possible, mount the temporary directory with the noexec option to prevent malicious file execution.

4. Check for signs of compromise: Given the recent mining exploits, check for suspicious processes running under the Gitea service account, especially those with high CPU usage or connections to unknown external IPs or mining pools. Look for unusual scheduled tasks and newly added hook files. If you find any suspicious activity, isolate the host and take remedial action immediately.

Note: These actions involve version upgrades and changes to network or permission policies. Before implementing them, test their impact on your existing CI and code hosting workflows in a staging environment. Always back up your data and configurations.

WordPress "wp2shell" remote code execution vulnerability

WordPress is a popular PHP-based application for building websites, often used as both a blog platform and a content management system (CMS). In July 2026, security researchers disclosed two high-risk vulnerabilities that can be chained together, collectively known as "wp2shell." An unauthenticated attacker can exploit these vulnerabilities remotely. By abusing a path confusion issue in the /batch/v1 REST API endpoint, an attacker can send arbitrary SQL queries to steal sensitive data from the database. After obtaining an administrator's password hash, they can then achieve remote code execution by uploading a malicious plugin and gain full control of the site. Technical details and a PoC are publicly available.

Affected versions: WordPress 6.8.0 to 6.8.5 (affected only by CVE-2026-60137), 6.9.0 to 6.9.4, and 7.0.0 to 7.0.1 | Secure versions: WordPress 6.8.6 and later, 6.9.5 and later, and 7.0.2 and later

If you are using an affected version of WordPress, perform the following checks and take immediate action:

1. Upgrade to a secure version (Recommended): Official patches are available. Please upgrade after assessing business compatibility. Releases are available at: https://github.com/WordPress/wordpress-develop/tags

2. Apply temporary mitigations: Use a WAF or ESA to block requests to /wp-json/batch/v1 and /?rest_route=/batch/v1. Alternatively, use the Disable WP REST API plugin to block unauthenticated access to the REST API, but note that this may affect features that rely on the API. You can also use the custom plugin released by Searchlight Cyber (see wp2shell.com) to enforce authentication for the REST Batch API.

3. Investigate and detect: Check if your WordPress version is in the affected range. Review server logs for suspicious batch requests targeting the /batch/v1 endpoint. You can also use the online scanner provided at wp2shell.com to run a targeted scan.

Always back up your data before upgrading to prevent data loss.

Fastjson 1.x deserialization remote code execution vulnerability (CVE-2026-16723)

Fastjson is a high-performance, open-source Java library from Alibaba for serializing and deserializing Java objects to and from JSON. In July 2026, security researchers disclosed a high-risk remote code execution vulnerability (CVSS 9.0) affecting Fastjson 1.x. The vulnerability allows for a "gadget-free" exploit, meaning an attacker can construct a malicious payload using only Fastjson's own deserialization logic. This enables arbitrary code execution without requiring any third-party gadget classes in the target environment, rendering traditional mitigations like blacklisting or removing dangerous classes ineffective. Because Fastjson 1.x reached its end-of-life in 2024, it will not receive a patch.

Affected versions: 1.2.68 to 1.2.83 | Secure version: Fastjson 2.x (current latest is 2.0.61)

If you are using an affected version of Fastjson, take the following actions immediately:

1. Migrate to Fastjson 2.x (Recommended): Version 2.x eliminates these design flaws at an architectural level and is secure by default. Before upgrading, review the official compatibility documentation to ensure compatibility.

2. Enable SafeMode to completely disable the AutoType feature: Use the JVM parameter -Dfastjson.parser.safeMode=true or set it in your code with ParserConfig.getGlobalInstance().setSafeMode(true).

3. Use the noneautotype version: Use the Maven coordinate com.alibaba:fastjson:1.2.83_noneautotype. This version removes the AutoType capability at compile time, eliminating the deserialization risk at its source.

Kafka-UI unauthenticated remote code execution vulnerability (CVE-2026-5562)

Kafka-UI is a widely used open-source visual management tool for Apache Kafka, often deployed on corporate intranets. In April 2026, a code injection vulnerability was disclosed in the tool: the /api/smartfilters/testexecutions endpoint fails to perform authentication, role, and feature switch validation when processing the filterCode parameter, and directly executes arbitrary incoming Groovy code. Because authentication is disabled by default, attackers can remotely execute operating system commands without credentials, which enables them to read sensitive information, exfiltrate data, and perform lateral movement on the internal network. A Proof of Concept (PoC) has been publicly disclosed and can be automated for exploitation, the vendor has not responded, and no official patch is available, so the risk persists.

Affected versions: 0.7.0 to 0.7.2 | Secure versions: None available (Vendor has not responded; mitigation is required)

If you are using an affected version of Kafka-UI, perform the following checks and take immediate action:

1. Limit public exposure (Recommended): Check if Kafka-UI is exposed to the public internet or a wide internal network. Use security groups, a firewall, or network segmentation to restrict access to the smallest possible set of trusted sources, such as an operations jump server. Never expose it directly to the internet.

2. Enable and enforce authentication: Kafka-UI lacks authentication by default. Configure a login mechanism (such as setting auth.type with OAuth2 or LDAP) by following the official documentation. Alternatively, enforce authentication with Basic Auth or SSO on a reverse proxy (such as Nginx) in front of the application to prevent unauthenticated access.

3. Temporarily disable the high-risk feature: If your business does not rely on the smart filter feature, you can block requests to the /api/smartfilters/testexecutions path on the reverse proxy until a patch is released. You can also use WAF rules to block related injection signatures.

4. Continuously track and monitor: Follow the official provectus/kafka-ui repository for patch announcements and upgrade as soon as a fix is released. In the meantime, monitor the Kafka-UI host for suspicious process creation and outbound network connections.

Note: These mitigations involve changes to network policies and authentication configurations. Before implementing them, test their impact on your existing operational workflows in a staging environment and back up your configurations to avoid disrupting normal Kafka management tasks.