Two vulnerabilities rated CVSS 4.0 at 9.2 could expose PHP-powered websites and servers to remote code execution. Patchstack reports active exploitation, while administrators await an emergency security release scheduled for 14:00 UTC today.

The PHP ecosystem is facing an urgent security incident following the disclosure of two critical vulnerabilities in the PHP interpreter that reportedly allow remote code execution (RCE). Tracked as CVE-2026-109618 and CVE-2026-109619, the flaws have prompted an emergency security release from the PHP development team, scheduled for Wednesday, October 21, at 14:00 UTC.

The situation has escalated beyond a routine vulnerability disclosure. In an October 21 advisory, security company Patchstack reported receiving multiple reports of active exploitation from hosting partners, with the first incidents in its published timeline recorded at 07:34 UTC. The reports raise the urgency for organizations running PHP-based websites, applications, and backend services.

The PHP security team confirmed the upcoming release in an official announcement published on October 20, assigning both vulnerabilities a severity rating of 9.2 under CVSS v4.0. The team urged users to prepare to upgrade immediately when patched versions become available and reserved the option to release earlier if technical details became public or evidence of exploitation emerged.

Sources: PHP security announcement, Patchstack security alert, Mallory’s technical analysis.

Two critical flaws in PHP itself

Unlike vulnerabilities limited to a specific content management system or plugin, these issues reportedly affect PHP at the interpreter level. Consequently, the potential exposure extends across a broad range of applications, including WordPress, Drupal, Magento, Joomla, Laravel, and custom PHP deployments, provided they run an affected version.

Remote code execution vulnerabilities can allow an attacker to execute commands or code on a vulnerable server. Depending on the deployment’s permissions, isolation, and security controls, a successful attack could lead to website compromise, unauthorized access to application data, installation of persistent backdoors, or further movement into connected infrastructure.

Patchstack identifies the two vulnerabilities as CVE-2026-109618 and CVE-2026-109619 and reports that technical details leaked ahead of the planned coordinated disclosure. Security researchers at watchTowr reportedly reproduced one of the vulnerabilities, lending further weight to concerns about exploitability.

The incident has also been referred to as “PHP2Shell” in early reporting. The official PHP announcement, however, had not yet published the full technical details or definitive affected-version information at the time of writing.

Active exploitation changes the response timeline

The most significant development is the divergence between the initial pre-release assessment and the latest threat intelligence.

In its October 20 analysis, Mallory reported that it had not observed public exploit availability or confirmed in-the-wild exploitation at the time of publication. The company nevertheless warned that exploitation could emerge quickly once technical details became available.

Patchstack’s October 21 update subsequently reported multiple exploitation incidents communicated by hosting partners. This later reporting suggests that defenders should no longer treat the issue solely as a forthcoming patching exercise.

The reports have not, by themselves, established the full scope of exploitation, the number of compromised systems, or whether every incident involved both vulnerabilities. Organizations should therefore treat the situation as a high-priority incident while avoiding assumptions about the scale or technical details of attacks that have not been independently confirmed.

The practical implication is clear: administrators should prepare for emergency patching now rather than waiting for evidence that their own systems are being targeted.

Hundreds of thousands of internet-facing hosts may remain unpatchable

Mallory’s analysis of internet-facing systems identified a substantial challenge beyond the immediate release: a large population of PHP installations runs end-of-life branches that may not receive upstream fixes.

According to Mallory’s October 20 Shodan-based assessment, approximately 1.5 million internet-facing hosts reporting a PHP version were identified. Of these, 883,717 hosts—roughly 59%—were running PHP 8.1 or earlier, branches that Mallory classified as no longer receiving fixes for this release.

The analysis estimated that around 612,000 hosts were running PHP 8.2 through 8.5, the branches expected to receive patched releases. Mallory also cautioned that the true number of affected websites could be substantially higher: version banners do not identify every PHP host, and a single shared-hosting IP address can serve numerous websites.

These figures are exposure estimates, not confirmed counts of vulnerable or compromised systems. Some operating-system distributors may backport security fixes, and externally visible version information does not necessarily establish whether a particular installation is vulnerable.

Nevertheless, the figures highlight a difficult operational problem. Updating a supported PHP branch may be straightforward, but older deployments can require application compatibility testing, infrastructure changes, vendor intervention, or migration to a supported environment.

Emergency release scheduled for 14:00 UTC

The PHP security team has scheduled the security release for October 21, 2026, at 14:00 UTC. At the time of publication, that release is still forthcoming.

Mallory’s pre-release analysis identifies the following anticipated fixed versions:

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

These version numbers are based on Mallory’s reporting ahead of the release. Administrators should verify the final release announcement and vendor advisories before treating any version as definitively fixed.

PHP 8.1 and earlier are identified by Mallory as end-of-life branches without a corresponding upstream fix planned for this release. Organizations operating these versions should urgently establish an upgrade or containment plan.

The PHP team’s official announcement states that full vulnerability details, affected versions, and fixed versions will be published with the release. It also reserves the right to publish earlier if disclosure or active exploitation warrants it.

What administrators should do now

Organizations that operate PHP-powered services should prioritize the following measures.

1. Inventory all PHP deployments. Identify versions running on production servers, containers, staging environments, development systems, and managed hosting platforms. Check PHP-FPM, Apache’s mod_php, CGI-based deployments, and any additional runtime instances that may be overlooked.

2. Prepare to install the official security update immediately. Confirm how PHP is deployed and upgraded in each environment. Coordinate with hosting providers, application owners, and infrastructure teams so that the relevant systems can be patched as soon as verified updates become available.

3. Escalate end-of-life installations. If a deployment runs PHP 8.1 or earlier, contact the hosting provider or platform vendor about supported upgrades and security coverage. Where an upgrade cannot be completed promptly, consider restricting access to trusted networks, applying temporary access controls, or taking exposed systems offline when operationally feasible.

4. Review signs of compromise. Given Patchstack’s exploitation reports, monitor web-server and PHP logs, unexpected child processes, new or modified files in web roots, suspicious outbound connections, and unexplained changes to scheduled tasks or application accounts. Preserve relevant logs and investigate suspicious activity instead of assuming a successful update alone resolves a possible compromise.

5. Avoid relying on unverified workarounds. Patchstack discusses disabling PHP’s session upload-progress feature as a possible temporary mitigation:

session.upload_progress.enabled = Off

This setting may reduce exposure to a particular suspected attack path, but it is not a confirmed complete fix. It should be considered only as a temporary measure following technical review, and it must not replace the official security update.

6. Verify vendor and distribution advisories. Organizations using packaged PHP installations should confirm whether their Linux distribution or hosting provider supplies a backported security fix. Compare the vendor’s advisory and package status rather than relying exclusively on the upstream version string.

Why this incident matters

The incident demonstrates the security risk posed by vulnerabilities in widely deployed application runtimes. A flaw in PHP itself can cross application boundaries, placing websites and services with very different business purposes into the same potential exposure window.

It also underscores the importance of lifecycle management. End-of-life software can remain operational for years because of legacy dependencies, hosting limitations, or the cost of migration. When a critical vulnerability emerges, those systems can become especially difficult to defend because an upstream patch may not exist for their branch.

The combination of a public disclosure, reports of exploitation, and a large population of potentially unpatched hosts creates a narrow window for defenders to act. Asset discovery, reliable patch deployment, and incident monitoring are therefore as important as the vulnerability’s severity score.

What happens next?

The next major milestone is the PHP security release scheduled for 14:00 UTC on October 21. Its publication should establish the official affected-version ranges, confirmed fixes, and technical details needed to guide remediation.

Until those details are available, organizations should treat the two reported RCE vulnerabilities as a critical operational priority, validate their exposure, and prepare their upgrade procedures. Those running unsupported PHP versions should not assume that waiting for the scheduled release will make their systems safe.

With exploitation already reported by Patchstack, the central question for defenders is no longer simply when a patch will arrive. It is whether every exposed PHP installation can be identified, secured, and verified before attackers gain a foothold.

Sources and further reading

• PHP.net: Upcoming Critical PHP Security Release — October 20, 2026
• Mallory: PHP RCE in 8.5 and Earlier: CVE-2026-109618 and CVE-2026-109619
• Patchstack: Major security alert: PHP vulnerable to critical RCE, attacks ongoing
• CERT-EU: Security Advisory 2026-018

The post Critical PHP remote code execution flaws trigger emergency security response appeared first on Hacking News.

According to the Danish CPR administration, the incident occurred after unauthorized individuals exploited a legitimate access channel held by a Danish company that was permitted to query information from the CPR system.

The compromised information reportedly includes citizens’ names, addresses, CPR numbers and other personal details held in the national population register.

Protected addresses reportedly not affected

The authorities said their initial investigation found that the unauthorized access did not include the names and addresses of individuals who had opted for protected name and address registration.

However, the full scope and circumstances of the incident are still being investigated.

The CPR administration has terminated the company’s access to the system and is working with cybersecurity specialists and relevant authorities to establish how the unauthorized access took place, how long it continued, and what information was obtained.

Authorities investigate potential data breach

The incident has been reported to the Danish Data Protection Authority (Datatilsynet), while Danish police are investigating the case in cooperation with other relevant authorities.

The scale of the incident makes it particularly significant: with approximately 8.8 million registered individuals potentially affected, the exposed information could include highly sensitive identifiers that can be used to distinguish individuals in Denmark.

At this stage, the authorities have not publicly disclosed further details about the suspected attackers, the company whose access was abused, or the precise technical method used to obtain the data.

The investigation is ongoing, and additional information may be released as authorities establish the full extent of the breach.

The Danish Ministry of Higher Education and Science has published further information about the incident on its website.

Source: Danish Ministry of Higher Education and Science, “Omfattende uautoriseret adgang til borgeres CPR-oplysninger”, October 2026.

The post Unauthorized access to CPR database exposes personal data of 8.8 million danish citizens appeared first on Hacking News.

A critical security vulnerability in WordPress could allow an unauthenticated attacker to abuse page-template resolution to include a locally accessible PHP file outside the active theme directory, potentially leading to remote code execution (RCE) under specific server and theme configurations.

The vulnerability, tracked as CVE-2026-87902 and identified in GitHub’s advisory database as GHSA-7hp8-65ch-5whp, was disclosed by security researcher Robert Ressl and publicly documented by the WordPress project on September 22, 2026. WordPress rates the issue as Critical, with a CVSS v4 score of 9.2.

WordPress security advisory on GitHub

What is the vulnerability?

The issue resides in WordPress’s page-template resolution mechanism. According to the WordPress advisory, an attacker who does not need to authenticate can influence get_page_template() so that template resolution attempts to include a chosen, readable local .php file located outside the active theme directories.

On its own, local PHP file inclusion does not necessarily mean that every vulnerable WordPress installation can immediately be taken over. The advisory stresses that additional conditions must be present for the issue to become an RCE.

Those conditions involve both the WordPress theme and the underlying PHP/server environment.

Specific themes can expose the vulnerable code path

One prerequisite is that the active parent or child theme contains a top-level directory beginning with page-.

The WordPress security team specifically identifies examples including the legacy Twenty Twelve and Twenty Fourteen themes, along with third-party themes such as Neve, Hestia and Sydney.

This means that simply running an affected WordPress version does not, by itself, establish that a site is exploitable for RCE. Administrators should instead examine both their WordPress version and the structure of the active theme.

Server configuration can determine whether RCE is possible

The second major prerequisite is the presence of a suitable local PHP file that is readable by the web server account.

The advisory notes that pearcmd.php can provide a path from local PHP inclusion to code execution in environments where PHP’s register_argc_argv setting is enabled. The WordPress project specifically calls out the official PHP Docker image and default cPanel configurations using PHP versions before 8.5 as environments that can satisfy relevant conditions.

Consequently, the practical risk varies considerably between deployments. A vulnerable WordPress installation may be exposed to the path-traversal/file-inclusion component without necessarily meeting all the requirements for remote code execution.

Broad range of WordPress versions affected

The vulnerability has an unusually broad affected-version range.

According to the WordPress advisory, affected releases span from the 4.7 branch through the 7.1.1 release, with each maintained branch having its own affected version range.

The corresponding fixed releases include:

The project says the fix was backported to branches as far back as WordPress 4.7 as a courtesy to users of older releases.

WordPress urges immediate updates

WordPress 7.1.2 was released on September 22 as a security release specifically addressing this critical vulnerability. The official WordPress announcement recommends that administrators update affected sites immediately. Sites supporting automatic background updates may receive the update automatically.

WordPress 7.1.2 release announcement

The WordPress documentation also confirms that security fixes were made available across the older supported branches.

What administrators should do

Administrators should first determine whether their WordPress installation is running one of the affected versions and update to the corresponding fixed release.

Organizations managing large WordPress fleets should also identify installations using themes with top-level page-* directories and review PHP/server configurations that could satisfy the additional conditions described in the advisory.

Because the vulnerability does not require authentication and the potential impact includes confidentiality, integrity and availability compromise when the necessary conditions are met, delaying the security update increases exposure.

The WordPress project credits Robert Ressl for discovering and responsibly disclosing the vulnerability.

Bottom line

CVE-2026-87902 is not a universal one-click RCE affecting every WordPress installation. Exploitation to achieve code execution depends on a combination of an affected WordPress release, a qualifying theme structure, and particular server/PHP conditions.

Nevertheless, the combination of unauthenticated access, path traversal, local PHP file inclusion and the possibility of RCE makes the issue significant. WordPress has released fixes across a wide range of branches, with 7.1.2 serving as the current fix for the 7.1 branch.

Administrators should prioritize upgrading rather than attempting to mitigate the issue solely through theme or server configuration changes.

The post Critical WordPress vulnerability enables unauthenticated path traversal and conditional RCE appeared first on Hacking News.

A large dataset containing information on more than 7.3 million Chess.com users is being shared for free on two data leak forums.

The 15.5 GB dataset contains 7,337,395 user records. It includes email addresses, usernames, names, countries, chess ratings, subscription information and internal advertising audience tags.

The data was reportedly collected between July 26 and August 3, 2026, and was disclosed on August 12. According to an analysis by Ransomnews, the information appears to be genuine Chess.com data.

However, the available evidence does not point to a traditional data breach.

Instead, the structure of the dataset suggests that someone collected the information over time by scraping a non-public part of the Chess.com platform.

What the leaked data contains

The dataset is stored in a 744 MB 7-Zip archive that expands to about 15.5 GB. It contains one table with 38 fields and more than 7.3 million records.

The information includes usernames, user IDs, UUIDs, email addresses, names, countries, locations and account locales. It also contains account information such as chess titles, ratings, skill levels, premium status, verification flags and account activity dates.

About three quarters of the records reportedly contain an email address.

The dataset does not appear to contain passwords, password hashes or payment information. That means users should not assume their Chess.com passwords or payment details were exposed based on this dataset alone.

Some of the more unusual information is found in two fields called gam_audiences and audiences_member_of.

These fields contain Google Ad Manager audience information. Examples include groups related to trial eligibility, inactive users, experiments and rating based advertising.

These are not ordinary public profile fields and are not included in the Chess.com public API.

Evidence points to scraping

The most important question is not whether the data is real. It is how it was obtained.

Several details suggest that the dataset was collected gradually rather than taken directly from a compromised database.

The records have capture dates covering nine days, from July 26 through August 3. The number of records collected varied from roughly 72,000 to 267,000 per day.

That pattern looks more like an automated collection process running over several days than someone downloading an entire database at once.

There are also a significant number of duplicate users.

Around 7.4% of the user IDs appear more than once. Many of those repeated accounts were recorded on different days, while the information in the rows changed slightly between captures.

That is consistent with a scraper returning to accounts and collecting updated information.

A database export would normally not contain multiple versions of the same user record in this way.

The UUIDs also appear genuine

The analysis found another strong indication that the records came from Chess.com.

Of the 169,289 valid version 1 UUIDs examined, 169,287 contained creation timestamps that matched the account’s member_since value down to the second.

UUID version 1 values can contain a creation timestamp. The matching timestamps suggest that these are genuine identifiers issued by Chess.com rather than identifiers fabricated by the person distributing the dataset.

The total number of records also matches the 7,337,395 records claimed by the distributor.

There is a history of Chess.com scraping

This is not the first time Chess.com users have been affected by large scale scraping.

In November 2023, a threat actor published information connected to about 828,000 Chess.com accounts. The dataset contained a similar collection of user information.

At the time, Chess.com said the incident was not a data breach and that its infrastructure, user accounts and passwords were secure.

The earlier incident involved the platform’s find friends functionality. Attackers used externally obtained email addresses to discover whether those addresses were connected to Chess.com accounts and then collected information returned by the service.

Another scrape later affected hundreds of thousands of users.

The latest dataset appears to follow a similar pattern, but on a much larger scale.

What users should do

There is currently no evidence in the dataset that passwords or payment information were exposed.

Even so, users should be careful about targeted phishing emails.

Because the dataset contains email addresses, names, usernames, locations and information about account status, criminals could use it to create convincing messages aimed at Chess.com users.

Users should avoid clicking unexpected links claiming to offer account upgrades, password resets, prizes or security alerts.

It is also a good idea to use a unique password for Chess.com and enable any additional account security features that are available.

Chess.com has been contacted

Ransomnews says it contacted Chess.com about the dataset and was waiting for a response at the time of publication.

The data was not being sold. Instead, the distributor known as V0idix reportedly released it for free on two leak forums, although one copy was placed behind a reply-to-unlock requirement.

For now, the evidence points to a large scale scraping operation rather than a direct compromise of Chess.com’s internal systems.

That distinction is important. A dataset can contain genuine and sensitive user information without hackers having broken into the company’s core infrastructure.

The full impact will depend on how the data was collected and whether Chess.com identifies the non-public interface or functionality that allowed such a large amount of information to be gathered.

The post Chess.com data leak exposes records of 7.3 million users appeared first on Hacking News.

A newly disclosed security vulnerability affecting multiple Tenda router firmware versions has revealed the presence of a hidden authentication backdoor capable of granting attackers full administrative access without requiring legitimate login credentials.

The issue, tracked as CVE-2026-11405, was published by the CERT Coordination Center (CERT/CC) under Vulnerability Note VU#213560 on July 6, 2026. According to the advisory, the flaw exists in the web management interface of several Tenda devices and allows authentication to be bypassed through an undocumented mechanism embedded directly within the firmware.

Hidden backdoor in authentication process

Tenda routers rely on a web-based management interface protected by administrator credentials. However, researchers discovered that the firmware’s /bin/httpd web server contains an additional authentication path that is never exposed to users or documented by the vendor.

Under normal conditions, the login routine validates passwords using an MD5-based authentication process. If that check fails, the firmware unexpectedly performs a second verification by retrieving a hidden configuration value named sys.rzadmin.password.

Instead of using the standard authentication mechanism, the software directly compares the supplied password with this stored value in plaintext using a simple string comparison. If the values match, the device immediately creates an administrator session with full privileges.

Perhaps more concerning is that the username supplied during login is never validated. Any username can be used successfully, provided the hidden password matches the stored configuration value.

The result is an undocumented administrative backdoor that completely bypasses the normal password verification process.

Affected firmware versions

The vulnerability impacts the following firmware releases:

• US_FH1201V1.0BR_V1.2.0.14(408)_EN_TD
• US_W15EV1.0br_V15.11.0.5(1068_1567_841)_EN_TDE
• US_AC10V1.0re_V15.03.06.46_multi_TDE01
• US_AC5V1.0RTL_V15.03.06.48_multi_TDE01
• US_AC6V2.0RTL_V15.03.06.51_multi_T

Potential impact

An attacker who knows or discovers the hidden password can gain unrestricted administrative access to the router’s web interface, regardless of the configured administrator credentials.

Once authenticated, an attacker could:

• Modify network and router configuration.
• Change DNS settings.
• Disable or weaken security protections.
• Create persistent access to the device.
• Potentially use the compromised router as a stepping stone for attacks against other systems on the local network.

If remote management is enabled and exposed to the internet, the risk increases significantly because the administrative interface may be reachable from outside the local network.

No security patch available

At the time of disclosure, CERT/CC stated it was unable to establish contact with Tenda to coordinate remediation. As a result, no official firmware update or security patch is currently available.

Until a fix is released, users are advised to reduce their exposure by:

• Disabling remote web management if the feature is enabled.
• Limiting access to the router’s management interface to trusted local devices.
• Changing the default LAN IP address to make automated scanning less effective, while recognizing that this does not stop targeted attacks.

Responsible disclosure

The vulnerability was reported by an anonymous security researcher. The CERT/CC advisory was authored by Bob Kemerer.

Organizations and home users running the affected firmware versions should review their router configurations and restrict administrative access wherever possible until Tenda releases a security update.

Source: https://kb.cert.org/vuls/id/213560

The post Tenda routers found with hidden authentication backdoor allowing full admin access appeared first on Hacking News.

The backdoor wasn’t a smash-and-grab. It wasn’t noisy, and it wasn’t rushed. It was planted quietly and left to sit for eight months before anyone flipped the switch.

I traced the plugin’s history through 939 quicksave snapshots. The code tells a very specific story if you’re willing to read it line by line.

The plugin had been on the site since January 2019. The wpos-analytics module was always there, functioning as a legitimate analytics opt-in system for years. Nothing unusual. Nothing suspicious. Just another piece of boilerplate tracking code bundled into a widely used plugin.

Then came version 2.6.7, released August 8, 2025.

The changelog said:
“Check compatibility with WordPress version 6.8.2.”

What it actually did was add 191 lines of code, including a PHP deserialization backdoor. The class-anylc-admin.php file grew from 473 lines to 664.

Buried in that diff were three critical additions:

• A fetch_ver_info() method that calls file_get_contents() on a remote server and feeds the response directly into @unserialize()
• A version_info_clean() method that executes @$clean($this->version_cache, $this->changelog) where every variable originates from attacker-controlled serialized data
• An unauthenticated REST API endpoint with permission_callback: __return_true

That is a textbook arbitrary function call vulnerability. The attacker controls the function name, the arguments, and the execution flow. It’s full remote code execution, disguised as version metadata handling.

And then… nothing.

No activity. No payload. No exploitation.

For eight months.

Until April 5–6, 2026.

That’s when analytics.essentialplugin.com began serving malicious payloads to every site running these plugins. The dormant backdoor woke up simultaneously across hundreds of thousands of installations.

This wasn’t an opportunistic exploit. It was premeditated infrastructure.

The acquisition

The plugin wasn’t originally malicious. That’s what makes this case more concerning.

It was built by an India-based team—Minesh Shah, Anoop Ranawat, and Pratik Jain—operating under “WP Online Support” starting around 2015. Over time, they built a portfolio of more than 30 free plugins, many with paid upgrades. In 2021, they rebranded to “Essential Plugin.”

By late 2024, revenue had dropped between 35% and 45%. The business was listed for sale.

A buyer identified only as “Kris,” with a background in SEO, crypto, and online gambling marketing, acquired the entire portfolio in early 2025 for six figures through Flippa. The transaction wasn’t hidden. It was public. It was even featured as a success story.

Two days after the original developers’ final commits in May 2025, the ownership transition was complete. Author headers were changed. A new WordPress.org account appeared.

Then, on August 8, 2025, the first commit from the new owner landed.

It contained the backdoor.

The very first commit.

Timeline of a supply chain compromise

• February 2015 — Domain registered, plugin development begins
• October 2016 — First major plugin published
• August 2021 — Rebrand to Essential Plugin
• Late 2024 — Revenue decline, business listed for sale
• Early 2025 — Acquisition completed by “Kris”
• May 2025 — Original developers exit, new account takes over
• August 8, 2025 — Version 2.6.7 introduces backdoor under false changelog
• August 30, 2025 — WHOIS updated to a Zurich-based identity using ProtonMail
• April 5–6, 2026 — Backdoor activated, payload distribution begins
• April 7, 2026 — All plugins from the author closed in a single day
• April 8, 2026 — Forced patch pushed to all installations

Eight months from insertion to activation. No accidental discovery. No early trigger. Just patience.

The mass shutdown

On April 7, 2026, the WordPress.org Plugins Team took the nuclear option.

Every plugin from the Essential Plugin author account was permanently closed. More than 30 plugins disappeared in a single day. The author page now returns nothing. The distribution endpoint returns a simple message: {"message":"closed"}.

Among the affected plugins were widely used tools for sliders, galleries, WooCommerce displays, testimonials, and post grids—components embedded deep into production websites.

Here’s a list with some of the compromised wordpress plugins:

• Accordion and Accordion Slider — accordion-and-accordion-slider
• Album and Image Gallery Plus Lightbox — album-and-image-gallery-plus-lightbox
• Audio Player with Playlist Ultimate — audio-player-with-playlist-ultimate
• Blog Designer for Post and Widget — blog-designer-for-post-and-widget
• Countdown Timer Ultimate — countdown-timer-ultimate
• Featured Post Creative — featured-post-creative
• Footer Mega Grid Columns — footer-mega-grid-columns
• Hero Banner Ultimate — hero-banner-ultimate
• HTML5 VideoGallery Plus Player — html5-videogallery-plus-player
• Meta Slider and Carousel with Lightbox — meta-slider-and-carousel-with-lightbox
• Popup Anything on Click — popup-anything-on-click
• Portfolio and Projects — portfolio-and-projects
• Post Category Image with Grid and Slider — post-category-image-with-grid-and-slider
• Post Grid and Filter Ultimate — post-grid-and-filter-ultimate
• Preloader for Website — preloader-for-website
• Product Categories Designs for WooCommerce — product-categories-designs-for-woocommerce
• Responsive WP FAQ with Category — sp-faq
• SlidersPack – All in One Image Sliders — sliderspack-all-in-one-image-sliders
• SP News And Widget — sp-news-and-widget
• Styles for WP PageNavi – Addon — styles-for-wp-pagenavi-addon
• Ticker Ultimate — ticker-ultimate
• Timeline and History Slider — timeline-and-history-slider
• Woo Product Slider and Carousel with Category — woo-product-slider-and-carousel-with-category
• WP Blog and Widgets — wp-blog-and-widgets
• WP Featured Content and Slider — wp-featured-content-and-slider
• WP Logo Showcase Responsive Slider and Carousel — wp-logo-showcase-responsive-slider-slider
• WP Responsive Recent Post Slider — wp-responsive-recent-post-slider
• WP Slick Slider and Image Carousel — wp-slick-slider-and-image-carousel
• WP Team Showcase and Slider — wp-team-showcase-and-slider
• WP Testimonial with Widget — wp-testimonial-with-widget
• WP Trending Post Slider and Widget — wp-trending-post-slider-and-widget

This wasn’t a niche package. It was infrastructure.

The coordinated shutdown strongly suggests a shared code pattern across all plugins. And that pattern centers on the wpos-analytics module.

The payload vector

The attack chain is simple but effective:

1. Ship benign analytics module for years
2. Introduce backdoor via trusted update
3. Wait for adoption across installed base
4. Activate remote payload delivery simultaneously

The use of unserialize() on remote data is the critical piece. It allows object injection, which in turn enables arbitrary method calls depending on available classes. Combined with the $clean function call, it becomes a flexible execution primitive.

Because the endpoint required no authentication, any external trigger could initiate the chain.

This is not just a vulnerability—it’s a remotely controlled execution framework embedded in legitimate plugins.

This has happened before

If this feels familiar, it should.

In 2017, a buyer using the alias “Daley Tias” purchased the Display Widgets plugin, which had over 200,000 active installs, for $15,000. Within weeks, it was injecting payday loan spam. That same actor went on to compromise multiple plugins using identical tactics.

The Essential Plugin case follows the same playbook—just at a larger scale.

More plugins. More installs. More patience.

Patching and remediation

If you still have one of these plugins and haven’t received or trusted the forced update, the remediation path is straightforward:

• Delete the wpos-analytics/ directory entirely
• Remove the analytics loader block in the main plugin file (look for markers like “Plugin Wpos Analytics Data Starts” or wpos_analytics_anl)
• Bump the version string (e.g., append -patched)
• Repackage and reinstall the plugin

But plugin cleanup is only part of the story.

Check your wp-config.php.

The malware appends itself onto the same line as:
require_once ABSPATH . 'wp-settings.php';

Because it doesn’t add a new line, it’s easy to miss. If your config file is larger than expected—roughly 6KB more—you’re likely dealing with an active compromise. At that point, plugin removal isn’t enough. You need a full incident response.

The real problem: Trust

This wasn’t a zero-day exploit. It wasn’t a clever bypass of hardened defenses.

It was a business transaction.

A legitimate developer built trust over eight years. That trust was sold. The new owner inherited distribution rights and pushed malicious code through the same channel users had relied on for years.

There is no mechanism in the WordPress plugin ecosystem to flag a change of ownership. No alert to users. No mandatory review when commit access changes hands.

The acquisition was public. The buyer’s background was public. The risk signals were visible.

And nothing in the system reacted.

The Plugins Team acted quickly once the attack was discovered. But the critical window—the eight months between insertion and activation—passed without detection.

That’s the gap attackers are now targeting.

What to do now

If you manage WordPress infrastructure:

• Audit your plugins against the affected list
• Remove or patch anything from the Essential Plugin portfolio
• Inspect wp-config.php for inline injections
• Assume compromise if the backdoor was active and investigate accordingly

This wasn’t just an isolated incident. It’s a repeatable model.

Image source: Freepik

The post 30 WordPress plugins compromised, someone planted a backdoor in all of them appeared first on Hacking News.

A highly sophisticated supply chain attack has struck one of the most widely used JavaScript libraries in the world. Two malicious versions of the popular HTTP client axios—1.14.1 and 0.30.4—were published to npm after a maintainer account was hijacked, introducing a stealthy remote access trojan (RAT) affecting macOS, Windows, and Linux systems.

With over 100 million weekly downloads, axios sits at the core of countless applications. This incident represents one of the most precise and operationally advanced attacks ever observed in the npm ecosystem.

Immediate warning

If you installed:

• axios@1.14.1
• axios@0.30.4

Assume your system is compromised.

How the attack worked

1. Maintainer account hijack

The attacker gained control of a primary axios maintainer’s npm account and used it to publish malicious versions directly to npm—bypassing the project’s secure GitHub Actions release pipeline.

These releases:

• Appeared legitimate (same maintainer identity)
• Had no corresponding GitHub commits or tags
• Were published using a stolen long-lived npm token (not secure OIDC publishing)

2. Pre-staged malicious dependency

The attacker quietly published a package named:

This package:

• Mimicked a legitimate crypto library
• Included no obvious malicious code in its main files

• Contained a hidden postinstall script:

  “postinstall”: “node setup.js”

This script executed automatically during installation—no import required.

3. Dependency Injection into axios

The compromised axios versions added a single new dependency:

That’s it.

No other files changed. No malicious code inside axios itself.

This is what made the attack so dangerous:

• Static code inspection shows nothing suspicious
• The payload executes during install, not runtime
• The dependency is never actually used in the code

The payload: Cross-platform RAT dropper

Once triggered, the malicious dependency:

1. Executes instantly during npm install
2. Contacts a live command-and-control (C2) server
3. Downloads a platform-specific second-stage payload
4. Installs a remote access trojan
5. Deletes itself and wipes evidence

Within 2 seconds, the infected system is already beaconing to the attacker.

Anti-forensics: Designed to disappear

This attack didn’t just infect systems—it actively hid itself.

After execution:

• The malware deletes its own files
• Replaces its package.json with a clean decoy
• Spoofs its version to appear harmless (4.2.0 instead of 4.2.1)

Result:

• npm list shows a safe version
• No malicious scripts remain
• Only a leftover directory hints at compromise

Key detection signal:
If node_modules/plain-crypto-js exists at all, the dropper has already executed.

Attack timeline (condensed)

• ~18 hours before attack: Clean decoy package published
• Moments before release: Malicious version deployed
• 00:21 UTC: axios 1.14.1 published
• 01:00 UTC: axios 0.30.4 published
• ~03:15 UTC: Both versions removed from npm
• ~04:26 UTC: Malicious dependency replaced with security stub

Total exposure window: ~3 hours

Why this attack is exceptional

This wasn’t opportunistic—it was engineered:

• Pre-staged infrastructure and payloads
• Multi-version targeting (both modern and legacy users)
• Near-zero footprint in source code
• Rapid execution and self-destruction
• Anti-forensic version spoofing
• Bypassing trusted publishing pipelines

Every detail suggests deliberate, high-skill execution.

Detection & discovery

The attack was identified through behavioral monitoring tools that flagged:

• Unexpected outbound network connections
• Calls to a previously unseen domain during CI runs
• Anomalies in dependency trees

Notably, detection did not come from code review—but from runtime behavior analysis.

What you should do

If you may be affected:

1. Isolate the system immediately

2. Check for:

   node_modules/plain-crypto-js
3. Assume credentials and secrets are compromised
4. Rotate:
   • API keys
   • SSH keys
   • Tokens
   • Passwords
5. Rebuild systems from clean environments
6. Audit logs for suspicious outbound connections

Bigger picture: A supply chain wake-up call

This incident highlights a critical reality:

Modern supply chain attacks no longer rely on visible code changes—they exploit trust, automation, and developer workflows.

Key lessons:

• “No code changes” does not mean “safe”
• Dependencies can execute code without being imported
• Trusted publisher pipelines are essential—but not foolproof
• Behavioral monitoring is now mandatory, not optional

Source: StepSecurity

The post Axios compromised on NPM – Malicious versions deploy cross-platform RAT appeared first on Hacking News.

According to a Twitter post, the Claude code source code has been leaked via a map file in their npm registry.

Claude code source code has been leaked via a map file in their npm registry!

Code: https://t.co/jBiMoOzt8G pic.twitter.com/rYo5hbvEj8

— Chaofan Shou (@Fried_rice) March 31, 2026

—

An interesting article about the Claude Code source code leak can be find on Alex Kim’s blog.

Comments:

Anthropic appears to have accidentally shipped a .map file with their Claude Code npm package, exposing the full readable source of the CLI tool. The package has since been pulled, but not before it was widely mirrored and dissected.

A few interesting findings from the leaked code:

• Anti-distillation mechanisms:
  The client can request “fake tool” injection to poison training data for anyone scraping API traffic. There’s also a system that summarizes intermediate outputs with signed blobs, so recorded traffic doesn’t contain full reasoning chains. Both mechanisms are feature-flagged and relatively easy to bypass.
• “Undercover mode”:
  A built-in mode prevents the model from revealing internal codenames or even mentioning “Claude Code.” Notably, it cannot be force-disabled in external contexts, meaning AI-generated contributions may intentionally appear human-authored.
• Frustration detection via regex:
  Instead of using an LLM, user frustration is detected with a simple regex matching phrases like “wtf,” “this sucks,” etc. Cheap and fast, if a bit ironic.
• Client attestation at the transport layer:
  Requests include a placeholder that gets replaced with a hash by Bun’s native HTTP stack (in Zig), allowing the server to verify requests come from an official binary. This acts like lightweight DRM for API access, though it’s gated behind flags and not airtight.
• Operational inefficiency:
  A comment notes ~250K API calls/day were being wasted due to repeated failures in a compaction routine. Fixed by adding a simple failure cap.
• KAIROS (unreleased):
  The code references a heavily gated autonomous agent mode with background workers, scheduled tasks, memory distillation, and GitHub integration—suggesting an always-on agent system in development.
• Other quirks:
  • A Tamagotchi-style “companion” system (likely an April Fools feature)
  • Game-engine-like terminal rendering optimizations
  • Extensive bash security filtering (23 checks, including Zsh-specific exploits)
  • Prompt caching treated as a first-class economic concern
  • A multi-agent orchestration system implemented via prompts rather than code

The broader takeaway: the leak is less about code quality and more about product strategy exposure. Feature flags and hidden capabilities (like KAIROS and anti-distillation efforts) reveal roadmap direction that competitors wouldn’t normally see.

There’s also an ironic angle: the leak may have been caused by a known Bun issue where source maps are served in production. If so, Anthropic’s own stack may have exposed its flagship product.

Overall, not catastrophic technically—but strategically awkward timing given recent enforcement actions against third-party clients using Claude APIs.

—

A GitHub user, Sigrid Jin was able to create a new project starting from the leaked Claude Code project:

At 4 AM on March 31, 2026, I woke up to my phone blowing up with notifications. The Claude Code source had been exposed, and the entire dev community was in a frenzy. My girlfriend in Korea was genuinely worried I might face legal action from Anthropic just for having the code on my machine — so I did what any engineer would do under pressure: I sat down, ported the core features to Python from scratch, and pushed it before the sun came up.

The whole thing was orchestrated end-to-end using oh-my-codex (OmX) by @bellman_ych — a workflow layer built on top of OpenAI’s Codex (@OpenAIDevs). I used $team mode for parallel code review and $ralph mode for persistent execution loops with architect-level verification. The entire porting session — from reading the original harness structure to producing a working Python tree with tests — was driven through OmX orchestration.

The result is a clean-room Python rewrite that captures the architectural patterns of Claude Code’s agent harness without copying any proprietary source. I’m now actively collaborating with @bellman_ych — the creator of OmX himself — to push this further. The basic Python foundation is already in place and functional, but we’re just getting started. Stay tuned — a much more capable version is on the way.

—

You can read more info and find about what exactly was leaked following this Discussion.

The post Anthropic accidentally published Claude Code source via npm source map appeared first on Hacking News.

In a sobering reminder that even widely trusted open-source projects can become collateral damage in geopolitical cyber conflict, the Notepad++ project has confirmed a prolonged and highly targeted supply-chain attack that compromised its update delivery infrastructure. The incident, which unfolded quietly over several months in 2025, did not stem from flaws in the Notepad++ codebase itself, but from an infrastructure-level breach at its former shared hosting provider.

The disclosure follows the initial security notice published alongside the Notepad++ v8.8.9 release and is the result of an extended investigation conducted jointly by external security experts, the project maintainer, and the hosting provider. The findings paint a picture of a patient, well-resourced adversary exploiting weaknesses beyond the traditional application layer.

Anatomy of the compromise

According to forensic analysis, the attackers gained unauthorized access at the hosting provider level, enabling them to intercept and manipulate network traffic destined for notepad-plus-plus.org. Rather than indiscriminate tampering, the operation was selective: update traffic from specific users was redirected to attacker-controlled infrastructure serving malicious update manifests.

The technical details of the initial intrusion remain under investigation, but investigators have ruled out vulnerabilities in the Notepad++ application itself. Instead, the compromise leveraged weaknesses in the hosting environment, granting adversaries visibility and control over update-related services. This distinction is critical: it underscores how trust relationships in software distribution pipelines can be abused without touching a single line of source code.

The campaign is believed to have begun in June 2025. Multiple independent security researchers, examining the tradecraft and targeting discipline involved, have assessed with high confidence that the threat actor was a Chinese state-sponsored group. The narrow targeting profile and sustained operational security are consistent with espionage-oriented objectives rather than criminal monetization.

Hosting provider findings

As part of the incident response, a dedicated IR plan was established, with direct coordination between the external response team and the hosting provider. The provider’s subsequent investigation yielded several key conclusions.

First, logs indicate that the shared hosting server responsible for handling the Notepad++ update endpoint was compromised until September 2, 2025. On that date, scheduled maintenance included kernel and firmware updates, after which no further evidence of active attacker access to the server itself was observed.

However, the threat did not immediately end there. Despite losing direct server access, the attackers had retained credentials to internal services associated with that environment until December 2, 2025. This residual access may have allowed them to continue redirecting portions of update traffic and returning malicious download URLs during that window.

Notably, the attackers showed no interest in other tenants on the same shared infrastructure. Logs reveal deliberate reconnaissance for the notepad-plus-plus.org domain, suggesting prior knowledge of weaknesses in older update verification mechanisms. Attempts to re-exploit the environment after remediation were detected and blocked, indicating that the attackers actively tested whether their access persisted.

By December 2, 2025, the provider had rotated all potentially exposed credentials, patched the vulnerabilities believed to have enabled the compromise, and verified that no similar indicators of compromise existed across other hosting systems. Clients were proactively migrated to a new server as a precautionary measure early in the investigation.

Timeline reconciliation

There remains a modest discrepancy between assessments. The external security experts concluded that malicious activity ceased around November 10, 2025, while the hosting provider’s internal review identified potential residual access until December 2. Reconciling both views, the most conservative estimate places the full compromise period between June and December 2, 2025, at which point all attacker access was definitively terminated.

From a defensive standpoint, this conservative framing is appropriate. When attribution and dwell time are in question, assuming the longest plausible exposure window is the only responsible course.

Remediation and hardening

The Notepad++ maintainer has issued a direct apology to affected users and moved decisively to address the structural weaknesses exposed by the incident. The project’s website has been migrated to a new hosting provider with substantially stronger security controls, reducing reliance on shared infrastructure.

Equally important are the changes within the application itself. Beginning with v8.8.9, the WinGup updater now verifies both the digital certificate and the cryptographic signature of downloaded installers. The update service’s XML responses are also digitally signed using XMLDSig. Enforcement of certificate and signature verification for update metadata will become mandatory in the upcoming v8.9.2 release, expected within weeks.

These measures materially raise the bar against similar attacks, transforming what was once a soft trust boundary into a verifiable cryptographic chain.

Article source: https://notepad-plus-plus.org/news/hijacked-incident-info-update/

The post Notepad++ hijacked by state-sponsored actors appeared first on Hacking News.

The React Team has disclosed a critical security vulnerability affecting React Server Components that can allow unauthenticated remote code execution on affected servers. The issue is tracked as CVE-2025-55182 and carries a cvss score of 10.0, the highest possible severity rating.

Developers using React Server Components are strongly urged to upgrade immediately.

What happened

On November 29, security researcher Lachlan Davidson reported a flaw in how React decodes payloads sent to React Server Function endpoints. By crafting a malicious http request, an unauthenticated attacker could exploit this decoding logic and execute arbitrary code on the server.

Applications may still be vulnerable even if they do not explicitly define any React Server Function endpoints, so long as they support React Server Components. Additional technical details will be released after the fix rollout is fully complete.

Affected packages and versions

The vulnerability is present in versions 19.0, 19.1.0, 19.1.1, and 19.2.0 of the following packages: react-server-dom-webpack, react-server-dom-parcel, and react-server-dom-turbopack.

Fixed versions

The issue has been resolved in versions 19.0.1, 19.1.2, and 19.2.1. Any application using the affected packages should upgrade to one of these versions immediately.

Who is not affected

Applications that do not use server-side React code are not affected. Apps that do not use a framework, bundler, or plugin that supports React Server Components are also not affected.

Affected frameworks and bundlers

Several popular tools depend on or bundle the vulnerable packages. Known affected frameworks and bundlers include Next.js, React Router, Waku, @parcel/rsc, @vitejs/plugin-rsc, and Redwood SDK.

Additional upgrade instructions for these projects will be provided as they become available.

Hosting provider mitigations

The React Team has worked with multiple hosting providers to apply temporary mitigations. These mitigations should not be relied upon as a permanent solution, and applications must still be updated immediately.

Vulnerability overview

React Server Functions allow a client to call a function that runs on a server. React provides integration points used by frameworks and bundlers to allow React code to execute on both the client and the server. Client-side requests are translated into http requests that are forwarded to the server, where React deserializes them into function calls and returns the result.

An unauthenticated attacker can craft a malicious request to a Server Function endpoint that triggers remote code execution during deserialization. Further details will be shared once the rollout of fixes is complete.

Update instructions

Next.js

All users should upgrade to the latest patched version in their current release line.

npm install next@15.0.5 for 15.0.x
npm install next@15.1.9 for 15.1.x
npm install next@15.2.6 for 15.2.x
npm install next@15.3.6 for 15.3.x
npm install next@15.4.8 for 15.4.x
npm install next@15.5.7 for 15.5.x
npm install next@16.0.7 for 16.0.x

Users on Next.js 14.3.0-canary.77 or newer should downgrade to the latest stable 14.x release.

npm install next@14

React Router

Applications using React Router unstable rsc apis should ensure the following dependencies are upgraded.

npm install react@latest
npm install react-dom@latest
npm install react-server-dom-parcel@latest
npm install react-server-dom-webpack@latest
npm install @vitejs/plugin-rsc@latest

Expo

Developers should consult the guidance published on expo.dev/changelog to learn more about mitigation options.

Redwood SDK

Ensure your application is running rwsdk version 1.0.0-alpha.0 or newer.

npm install rwsdk@latest
npm install react@latest react-dom@latest react-server-dom-webpack@latest

Waku

Upgrade all relevant dependencies to their latest versions.

npm install react@latest react-dom@latest react-server-dom-webpack@latest waku@latest

@vitejs/plugin-rsc

Upgrade the rsc plugin and related dependencies.

npm install react@latest react-dom@latest @vitejs/plugin-rsc@latest

react-server-dom-parcel

npm install react@latest react-dom@latest react-server-dom-parcel@latest

react-server-dom-turbopack

npm install react@latest react-dom@latest react-server-dom-turbopack@latest

react-server-dom-webpack

npm install react@latest react-dom@latest react-server-dom-webpack@latest

Timeline

November 29: Lachlan Davidson reported the vulnerability through the Meta bug bounty program.
November 30: Meta security researchers confirmed the issue and collaborated with The React Team.
December 1: A fix was completed and coordinated with hosting providers and open source projects.
December 3: The fix was published to npm and the vulnerability was publicly disclosed as CVE-2025-55182.

Attribution

The React Team thanks Lachlan Davidson for responsibly discovering, reporting, and assisting in the remediation of this vulnerability.

Source: React blog, critical security vulnerability in React server components, December 3, 2025

Status Update 12 December 2025: New RSC vulnerabilities identified

Two additional vulnerabilities (CVE-2025-55184 and CVE-2025-55183) have been identified in the React Server Components (RSC) implementation used by frameworks including Next.js. These issues were uncovered by an external security researcher participating in Vercel and Meta’s bug bounty program, following increased community scrutiny after the React2Shell incident. We appreciate the continued collaboration and responsible disclosure efforts. At this time, there is no evidence of exploitation in the wild.

Vulnerability details

• CVE-2025-55184 — High Severity (Denial of Service):
  Specially crafted HTTP requests sent to any App Router endpoint can cause the server to hang and consume excessive CPU during deserialization. All versions handling RSC requests are affected.

• CVE-2025-55183 — Medium Severity (Source Code Exposure):
  Malicious HTTP requests to App Router endpoints may result in compiled Server Action source code being returned. While this could expose business logic, secrets are not at risk unless hardcoded directly in Server Action code.

Required action

These vulnerabilities impact React versions 19.0.0–19.2.1 and Next.js versions 13.x–16.x.
If you are running an affected version, upgrade immediately, even if additional mitigations are in place.

The post Critical security vulnerability in React Server Components enables unauthenticated RCE appeared first on Hacking News.