Editor’s note (February 2025): This article was originally published in January 2007. While the specific vulnerability discussed has long been patched, we’ve preserved and updated this piece as a historical document showing how WordPress security concerns have evolved.
In early 2007, security researcher David Kierznowski discovered a Cross-Site Scripting vulnerability in WordPress’s templates.php file that could allow malicious code injection into WordPress core files. The vulnerability, later assigned CVE-2007-1049, affected nearly all WordPress versions prior to 2.0.6.
The technical details were straightforward if you knew what to look for: when editing files, WordPress created a shortcut titled “recently accessed files.” While the anchor tag text was properly escaped, the link title was not sanitized before being passed to the get_file_description function. This allowed attackers to inject arbitrary web scripts or HTML code through the file parameter.
For bloggers who weren’t security experts, the practical implication was clear: attackers could potentially steal cookie-based authentication credentials, control how your site rendered to users, or execute other malicious code within your blog’s context.
The 2007 Response
The WordPress community responded with the tools available at the time. Bloggers who couldn’t immediately upgrade—due to heavy customizations, incompatible templates, or plugin dependencies—had two workaround options: comment out line 72 in /wp-admin/templates.php, which contained the vulnerable update_recently_edited($file) function, or replace the file with a patched version from the WordPress development branch.
This incident showcased what many considered a strength of open source software: vulnerabilities could be identified and resolved by the community, rather than waiting for a centralized development team.
What’s Changed Since 2007
WordPress has matured dramatically in the eighteen years since this vulnerability was disclosed. Automatic updates, introduced in WordPress 3.7 (2013), now push security patches to sites without requiring manual intervention. The WordPress security team responds rapidly to core vulnerabilities, and the platform’s update infrastructure reaches millions of sites simultaneously.
But here’s what’s remarkable: the fundamental vulnerability type that threatened WordPress in 2007 remains the most common threat in 2025. According to Patchstack’s State of WordPress Security report, Cross-Site Scripting accounted for nearly half of all WordPress vulnerabilities discovered in 2024—essentially the same attack vector that worried bloggers eighteen years ago.
The Modern WordPress Security Landscape
The scale of the challenge has changed dramatically. In 2024, researchers discovered 7,966 new vulnerabilities in the WordPress ecosystem—a 34% increase over 2023. That number makes the single templates.php vulnerability from 2007 seem almost quaint.
The difference is where these vulnerabilities live. WordPress core is now remarkably secure, accounting for only about 4% of discovered vulnerabilities. The overwhelming majority—96%—are found in plugins and themes. The attack surface has expanded from WordPress itself to the ecosystem surrounding it.
This shift reflects how WordPress usage has evolved. In 2007, a typical WordPress blog might run with a handful of plugins for basic functionality. Today, WordPress powers over 40% of all websites, and many installations run dozens of plugins handling everything from e-commerce to email marketing to search engine optimization.
XSS: The Vulnerability That Won’t Die
Cross-Site Scripting remains stubbornly prevalent for the same reason it was a problem in 2007: it’s relatively easy to introduce and relatively easy for researchers to find. When developers fail to properly sanitize user input—exactly what happened with that templates.php file in 2007—attackers can inject malicious scripts.
The consequences have scaled with WordPress’s importance. An XSS vulnerability in 2007 might compromise a personal blog. In 2025, the same vulnerability class threatens e-commerce stores, membership sites, and enterprise applications. Stored XSS attacks can steal admin credentials, inject malware that affects every visitor, or turn compromised sites into platforms for further attacks.
The 2025 Patchstack mid-year report found that 41.5% of WordPress vulnerabilities were considered exploitable in real-world conditions—up from 30.4% the previous year. The attacks are getting more sophisticated, with AI-powered tools enabling attackers to scan thousands of sites rapidly and test multiple exploitation techniques simultaneously.
Lessons for Modern WordPress Publishers
The advice from 2007—keep WordPress updated—remains valid, but insufficient. Modern WordPress security requires a more comprehensive approach.
Automatic updates for WordPress core should be enabled, but plugin and theme updates require more attention. The uncomfortable truth from Patchstack’s research: more than half of plugin developers didn’t patch reported vulnerabilities before public disclosure in 2024. This means even diligent site owners can be running vulnerable code through no fault of their own.
Web Application Firewalls have become essential for blocking XSS and other attacks at the perimeter. Services like Wordfence, Sucuri, and Cloudflare provide protection that simply wasn’t available to bloggers in 2007. Regular security audits, strong authentication practices including two-factor authentication, and careful evaluation of which plugins you actually need have become baseline requirements rather than advanced precautions.
The Open Source Trade-off
The 2007 article praised open source for enabling community-driven vulnerability discovery and resolution. That remains true—Patchstack’s bug bounty program and security researchers around the world continuously identify WordPress vulnerabilities. But the same openness that enables rapid patching also enables rapid exploitation.
The European Union’s Cyber Resilience Act, which took effect in December 2024, will require open source developers including WordPress plugin authors to have processes for notifying authorities and users about vulnerabilities by September 2026. This regulatory pressure may accelerate the professionalization of WordPress security that’s been developing over the past decade.
Looking Back to Look Forward
That 2007 templates.php vulnerability was patched quickly and affected a relatively small number of sites by today’s standards. But it represented the beginning of a security conversation that continues nearly two decades later.
The fundamental challenge hasn’t changed: WordPress’s power comes from its extensibility, and its extensibility creates security complexity. Every plugin, every theme, every customization is a potential attack surface. The community has built increasingly sophisticated tools to address this—automatic updates, security plugins, managed hosting with built-in protection—but the underlying tension between flexibility and security remains.
For bloggers and publishers managing WordPress sites today, the lesson from 2007 still applies: take security seriously, stay updated, and don’t assume that any platform, no matter how mature, is immune to vulnerabilities. The attacks will keep evolving. So must the defenses.
