Security Lead Time: The Advantage of Working With a Developer Who Finds Vulnerabilities

There are currently 15 vulnerabilities listed for the Divi WordPress theme in the Wordfence Intelligence Vulnerability Database.

Six of them were discovered by me.

That means 40 percent of the Divi vulnerabilities currently documented by Wordfence came from security research I conducted.

I am proud of that work, of course. But the number itself is not the most interesting part.

The part that matters most to me is what those discoveries meant for the websites I was already responsible for.

Because when your web developer is also the person finding vulnerabilities in the software your website uses, something unusual happens:

You can start protecting the website before the rest of the world even knows there is something to protect against.

The Normal Vulnerability Timeline

Most website owners experience a security vulnerability near the end of its lifecycle.

A security researcher discovers an issue.

The researcher validates it.

The vulnerability is responsibly disclosed to the software vendor.

The vendor investigates the problem.

A patch is developed and released.

Eventually, the vulnerability may appear in public vulnerability databases. Security companies can analyze it, scanners begin identifying affected installations, and security products may introduce specific protections or virtual patches.

Only then does the average website owner hear about it.

By that point, a considerable amount of work has already happened behind the scenes.

I experienced that process firsthand with Divi.

Divi version 4.27.7, released on May 12, 2026, contained five separate security fixes resulting from vulnerabilities I responsibly disclosed.

Those fixes addressed vulnerabilities involving Social Media Follow URL handling, Contact Form redirects, legacy Dynamic Content, server-side requests during video thumbnail processing, and the Video Slider module.

The Divi 4.27.7 changelog credits me for the responsible disclosure of all five issues.

Today, all five also appear in the Wordfence Intelligence vulnerability database under my name:

• CVE-2026-3853: DOM-Based Stored Cross-Site Scripting
• CVE-2026-4361: Server-Side Request Forgery
• CVE-2026-3852: Stored Cross-Site Scripting via Social Media Follow
• CVE-2026-3850: Stored Cross-Site Scripting via Contact Form redirects
• CVE-2026-3851: Stored Cross-Site Scripting via legacy Dynamic Content

Those five belong to the Divi 4 branch and were all fixed in the same release.

The sixth is more recent, and it is a different kind of problem.

CVE-2026-91707 affects Divi up to and including 5.11.1 and was patched in 5.12.0. It is a missing authorization issue that allowed arbitrary registered shortcodes to be executed through the content parameter of a Shortcode Module REST endpoint.

The word that matters there is unauthenticated. Exploitation did not require an account on the target site.

Wordfence scored it 5.3, in the medium range, because what an attacker can actually accomplish depends on which shortcodes are registered on the site being attacked. That is exactly the sort of impact that varies from one installation to the next, which is another way of saying that the score in the database is not the same thing as the risk to your particular website.

It was published on September 17, 2026. One day before this article.

But My Clients Did Not Have to Wait for the CVEs

This is where security research intersects with my day-to-day work as a web developer.

I do not just research WordPress vulnerabilities.

I also maintain WordPress websites.

When I discover a vulnerability in a component used by a website under my care, I do not have to wait for Wordfence to publish a CVE before I understand the risk.

I already found it.

I already analyzed how it works.

I already understand the conditions required to exploit it.

And while responsible disclosure prevents me from publicly revealing technical details before the vendor has had an opportunity to fix the issue, it does not prevent me from responsibly evaluating the exposure of the systems I maintain.

That creates something I call security lead time.

It is the mirror image of a problem I wrote about in The WordPress SVG Security Gap Nobody Is Incentivized to Report: a whole class of weaknesses that never becomes a CVE at all, because no reporting program is incentivized to document it. The absence of a vulnerability alert has never been the same thing as the absence of a vulnerability. Here the alert does eventually arrive. It just arrives late.

What Is Security Lead Time?

Security lead time is the period between understanding that a security problem exists and that information becoming broadly available to everyone else.

Normally, website owners depend on someone farther down the chain.

They wait for the vendor to release an update.

They wait for a vulnerability scanner to detect an affected version.

They wait for Wordfence, Sucuri, Cloudflare, their hosting provider, or another security service to introduce a rule or alert.

Those systems are valuable. I use security products and strongly believe in layered security.

But they are still layers in a larger system.

Sometimes knowledge comes before the defensive product.

And if the person maintaining your website possesses that knowledge, the defensive timeline can begin earlier.

This Is Why Specialization Matters

"Web developer" is an extremely broad job description.

Two developers can both be excellent at their jobs while having completely different areas of expertise.

One developer may specialize in UI and visual implementation.

Another may specialize in eCommerce.

Another in performance.

Another in accessibility.

Another in infrastructure.

Another in automation and integrations.

Security is one of my specialties.

I spend time analyzing WordPress code specifically to understand where assumptions fail, where trust boundaries break down, and what happens when software receives input that its developers did not anticipate.

That changes the way I approach ordinary development work.

Once you regularly search for cross-site scripting, privilege escalation, authorization failures, SQL injection, server-side request forgery, arbitrary file access, and other vulnerability classes, you begin looking at websites differently.

You stop thinking only about whether a feature works.

You also think about how it can fail.

Who can access it?

What happens if an expected value is replaced with an unexpected one?

Where is input validated?

Where is output escaped?

Which security decision is being delegated to another component?

What assumptions are being made about the user?

It is the same habit Red-Team the Work, Not the People describes for creative work: find what the system assumes will always be true, then systematically make those assumptions false.

That mindset follows you into every website you maintain.

Security Software Is Important. Expertise Is Another Layer

This is not an argument against Wordfence, Sucuri, Cloudflare, security scanners, web application firewalls, or automatic updates.

Quite the opposite.

Good security depends on layers.

Security and Quality Are Like an Onion makes that argument at length, and the important part of it is not that there are many layers. It is that they fail independently.

A firewall may stop an attack.

A malware scanner may detect a compromise.

A vulnerability database may identify an affected component.

A hosting provider may block a malicious request.

A vendor patch may eliminate the vulnerability entirely.

Each layer has a purpose.

But there is another possible layer that does not get discussed as often:

the person maintaining the website.

If that person also researches vulnerabilities, reads source code from an adversarial perspective, understands exploitation, and participates in responsible disclosure, that expertise becomes part of the client's security posture.

Not as a product.

As knowledge.

Six Out of Fifteen

When I look at the Divi page in the Wordfence Intelligence Vulnerability Database today, I see 15 documented vulnerabilities.

My name is next to six of them.

That is 40 percent of the vulnerabilities currently listed for that theme.

But what makes that meaningful to me is not seeing my name in the database.

It is knowing that during the period between discovery and disclosure, the websites I was responsible for had someone on their side who already understood those weaknesses.

Before the CVEs.

Before the public vulnerability records.

Before most administrators knew those specific issues existed.

That is the practical value of specialization.

The Best Security Work Often Looks Like Nothing Happened

Good security is strange because success is frequently invisible.

There is no dramatic incident.

No malware cleanup.

No emergency call.

No compromised website.

No client asking why their website suddenly redirects visitors somewhere else.

Nothing happens.

And that is exactly the point.

The client may never know about the vulnerability research, the disclosure process, the risk evaluation, or the mitigation decisions happening behind the scenes.

What they experience is simply a website that continues operating normally.

When you hire a specialized developer, you are not only paying for what that person can build.

You are also benefiting from what they know.

Sometimes that knowledge gives you better architecture.

Sometimes it prevents a bug.

Sometimes it makes a website faster.

And sometimes it gives you something especially valuable in cybersecurity:

time.

Time before public disclosure.

Time before widespread scanning.

Time before an exploit becomes common knowledge.

Time to understand your exposure.

Time to act.

That is security lead time.

And sometimes knowing earlier is one of the strongest security advantages you can have.