WordPress Releases Version 7.1.3 Amid Increased Security Concerns
On October 6, WordPress unveiled version 7.1.3, a pivotal security update designed to address seven vulnerabilities within the core software.
While the announcement of such updates is often routine, the frequency of these releases is anything but ordinary.
This iteration marks the third security update within a span of fewer than three weeks, following version 7.1.1 on September 17 and version 7.1.2 on September 22.
Since mid-July, this marks the sixth release, culminating in a total of 34 security vulnerabilities rectified in under 12 weeks.
Historically, core security releases from WordPress occurred a few times each year, with critical vulnerabilities primarily residing within plugins.
Notably, while this latter fact remains consistent, scrutiny of the core has intensified. According to Patchstack’s State of WordPress Security report published in February, 11,334 new vulnerabilities were identified within the WordPress ecosystem in 2025; a staggering 91 percent were found in plugins, with only six affecting the core.
The rigorous examination of the core is now evidenced by the credits in the release notes, shedding light on the entities involved in these discoveries.
Among the seven fixes in version 7.1.3, three are attributed to Anthropic, an artificial intelligence firm. Two additional vulnerabilities in version 7.1.1 also bear this credit, along with one co-credited to pwn.ai, a company specializing in autonomous penetration testing.
Notably, pwn.ai also identified the remote code execution vulnerability addressed in version 7.0.4 in August.
Furthermore, the critical vulnerability patched in version 7.0.2 on July 17 was reportedly uncovered by Searchlight Cyber utilizing an OpenAI model to probe WordPress’s core.
This model managed to devise an effective attack within approximately ten hours, with an estimated cost of around $25.
An analysis by Patchstack reveals that the WordPress bug bounty program, which encompasses core vulnerabilities, the WordPress.org infrastructure, and official plugins, has seen monthly report submissions consistently rise, from dozens over nine years to 450 reports in July alone.
The underlying narrative reflects a positive development. These vulnerabilities were identified by vigilant researchers who privately reported them, adhering to the established protocols for responsible disclosure.
Consequently, software upon which millions of businesses depend is now undergoing heightened scrutiny, facilitating the surfacing of longstanding issues.
Conversely, there exists a more pressing narrative concerning the temporal nature of these updates. The very instruments that assist researchers in uncovering flaws concurrently aid potential attackers in deciphering patches.
Once a fix is publicized, the code alterations become readily accessible to all. The release of version 7.1.2 on September 22 exemplifies this phenomenon.
It rectified a critical vulnerability in how page templates were loaded, enabling anonymous users to potentially execute code on certain server configurations. This issue affected all versions from 4.7 to 7.1.1.
Patchstack, which administers a firewall across numerous WordPress sites, noted the initial attempts to exploit this vulnerability at 11:49 AM UTC on the same day.
Just before midnight in New Zealand, attackers were already attempting to compromise vulnerable servers.
Within four hours, emergent attack traffic had swelled to more than ten times the volume seen on that initial evening, accompanied by circulating scanning tools.
A business owner in New Zealand who retired for the night with an unprotected site faced an unwelcome surprise upon waking—issues that had not existed beforehand.
Patchstack’s analysis from August articulated this urgency starkly: “If research is progressing at this pace, the notion of ‘we’ll address it during a maintenance window’ is a strategy suited for a threat landscape that has already evolved.”
This deluge is not entirely beneficial. On October 1, Google announced it had halted acceptance of product vulnerability reports to its open source bug bounty program.
This suspension was attributed to a significant increase in automated submissions, the majority of which proved invalid.
Volunteers managing open source projects now confront the daunting task of differentiating authentic AI-assisted findings from spurious machine-generated data.
This burden is not reflected in financial statements for New Zealand businesses, yet it undoubtedly influences the speed at which vulnerabilities are remedied.
The significance of this situation is underscored by a simple mathematical reality. According to W3Techs, WordPress powers 40.1 percent of all websites, and an impressive 58.6 percent of identifiable content management systems.
W3Techs further highlights that approximately 35 percent of WordPress sites remain on version 6 or older.
While WordPress does extend security fixes to older branches, currently as far back as version 4.7, its official notes clarify that only the latest version receives active support. Sites operating on versions 4.6 or earlier receive no updates whatsoever.
On a more encouraging note, WordPress is equipped with mechanisms designed for precisely this scenario.
Minor security releases, including version 7.1.3, can install automatically on sites enabled for background updates—a default setting for most.
However, numerous business websites have disabled this feature, often due to developers fearing that updates may disrupt customized functionalities, or as part of hosting strategies that implement collective monthly updates.
Such decisions made sense in an era when serious core vulnerabilities emerged once or twice a year. Now, with the interval between a patch’s deployment and the onset of attacks shrinking to mere hours, these choices have become increasingly precarious.
Consequently, businesses operating WordPress sites must grapple with several practical inquiries. Are automatic minor updates activated?
If not, who made that decision, and based on what reasoning? If a site relies on an older version, is it at least running the latest point release for that branch, and what plans exist for transitioning to the current version?
When a critical update is published at midnight, who bears the responsibility for ensuring its implementation by morning?
It is vital that they are well-informed about the necessary actions. Moreover, as the threat landscape remains heavily populated by plugin vulnerabilities, similar inquiries must extend to every plugin incorporated on the site.
For developers and hosting providers, the list of considerations expands. Maintain lean PHP configurations, particularly as the 7.1.2 attacks exploited specific server settings and unnecessary PHP components.
Employ firewalls capable of implementing virtual patches, as Pantheon demonstrated across its platform for version 7.1.3.
Treating security releases as immediate priorities rather than relegating them to subsequent development sprints is imperative.
While several fixes in the current batch require an attacker to possess valid login credentials, version 7.1.3 is comparatively less alarming than its predecessor.
Nevertheless, it does encompass a vulnerability allowing unauthorized visitors to view comments on private and unpublished posts. Sites that have not been updated since Tuesday should be scrutinized with diligence.
Artificial intelligence is not rendering WordPress less secure. Quite the contrary, it accelerates the fortification of the core software at an unprecedented rate.
What has altered is the tempo of the process: discovering vulnerabilities is no longer the protracted phase; rather, it is the subsequent remediation that defines the current pace.
For the majority of enterprises, the Achilles’ heel lies not in the code per se, but in the elapsed time between a patch’s issuance and its actual installation.
Source link: Newswire.co.nz.
