“The emergency patch is out, but we don’t know which sites are affected”—where CMS vulnerability response really gets stuck

“The patch is already out. But wait—which client sites was this plugin even installed on?”

For production agencies managing multiple CMSs and websites, this kind of moment is all too familiar.

When a vulnerability alert comes in, the ideal response is clear: identify the affected sites, decide priorities, contact the client, and move quickly to apply the patch.

But in the real world, the first bottleneck often is not the technical work.
It is figuring out which sites are affected, who needs to be contacted, and in what order the response should happen.

We have been there too.

In May 2026, serious vulnerabilities in WordPress plugins were reported one after another in a short span. A contact-form plugin had a flaw that could lead to site takeover and was actively exploited. An analytics plugin had a high-severity flaw that allowed attackers to impersonate an administrator.

Depending on the plugin, the affected scope ranged from thousands to hundreds of thousands of sites. In some cases, exploitation began only a few hours to a few days after the patch became public.

This was the kind of situation where every hour mattered.

And yet, the first thing we did was not patching.
We were scrambling through people’s memories and old email threads, asking, “Which client sites were using this plugin?”

Nearly half a day disappeared there.

In this article, we will share how we reorganized our CMS vulnerability response process for agencies managing multiple client sites.

---

Why this problem happens

When CMS vulnerability response takes too long, the cause is not always the difficulty of applying the patch.

In many cases, teams get stuck before the technical work even begins.

Background 1: site setup information is not up to date

When an emergency patch is released, you need information such as:

• Which CMS is used on each site
• Which plugins are installed
• What version each plugin or CMS is on
• Who decides whether an update can be applied
• Who the client-side contact is

None of this information becomes necessary only after an emergency happens.
It is information that should already be organized during normal operations.

But in our previous workflow, this information was scattered across per-site handover notes, old documents, and the memory of whoever happened to be in charge.

When assignments changed, memory faded.
When time passed, notes stopped being updated.

It did not cause much trouble during calm periods.
But in an emergency, it suddenly became a serious bottleneck.

Background 2: the contact chain and decision-maker are unclear

CMS vulnerability response is not only about whether the patch can technically be applied.

There are also decisions to make:

• Can the patch be applied to production immediately?
• Should it be tested in staging first?
• What should be done if the layout breaks?
• When and how should the client be informed?

If the team does not know who to contact or who can make the decision, the response stops there.

The patch may already be public.
The risk may already be real.
But if the affected sites and contact chain are unclear, the team cannot move fast.

---

Steps to solve the problem

What we changed was not a special emergency-only workflow.

We focused on making sure the information needed in an emergency could be accessed during normal operations.

We also standardized the steps for checking before and after updates.

STEP 1: make the current state visible

The first thing we did was consolidate each site’s setup and contact information into one place.

Today, for each project or site, we organize this information in the MONJI+ Wiki.
Shared rules for the whole team go into the Team Wiki, while site-specific information goes into each Project Wiki.

We record information such as:

• CMS in use
• Main plugins and what each one does
• Who makes update decisions
• Client-side contact information
• Past trouble spots
• How previous issues were handled

The important point is that this is not just a memo.
It needs to be organized as information that can be used immediately during an emergency.

For example, when an alert comes in about a vulnerability in a contact-form plugin, we can open the Wiki and quickly identify which sites may be affected.
We can also confirm who needs to be contacted from the same place.

MONJI+ Project Wiki supports permission control, so information that can be shared with clients and information that should remain internal can be managed separately.
For teams that want to organize site setup information and contact chains, MONJI+ can be used as the place to keep those records.

STEP 2: turn records into a monthly operation

The next thing we reviewed was how to keep those records from becoming outdated.

CMS and plugin information changes over time.
New plugins are added, unnecessary ones are removed, and the person in charge may change.

That is why we started checking site information as part of our regular monthly operations.

Alongside the Wiki, we keep each site’s admin URL in MONJI+ URL bookmarks.
Update runbooks and recovery files are stored in the project’s file storage.

This reduced the time spent looking for things such as:

• Where the admin URL is
• Where the update runbook is stored
• Where recovery files are located
• Where past response history is recorded

When the Wiki, URL bookmarks, and file storage are all organized inside the same project, it becomes much easier to confirm “which site, where to log in, and what to check.”

Not having to search across multiple tools and folders during an emergency makes a major difference in the first response.

STEP 3: standardize update checks and use the records for client communication

Once the setup information and contact chain were organized, we standardized the update work itself.

We created a checklist that we always use during emergency patch response.
It is registered in MONJI+ checklist feature and can be called up from the screen where we create feedback.

The checklist includes items such as:

1. Confirm the target plugin or CMS version and the patch to apply
2. Take screenshots of the display and key behavior before updating
3. Apply the patch in staging first
4. After applying to production, check that the target pages are not broken
5. Record what was done in the target site’s Wiki

The more rushed the situation is, the easier it is for steps to slip through the cracks.

That is why having the same checklist every time matters.
It helps keep the team grounded and brings the quality of response closer together, regardless of who handles the update.

These records also become useful when explaining maintenance work to clients.

Instead of saying only, “We performed maintenance,” we can show:

• Which site was updated
• What was checked before and after
• What issues were found
• How they were handled
• What was recorded to prevent recurrence

When several months of this history accumulate, the value of website maintenance becomes easier to communicate through actual records.

---

What changed in practice

After consolidating each site’s setup and contact chain into the Wiki, our first response changed significantly.

Previously, simply figuring out “which sites had this plugin installed” could take nearly half a day.
Now, by checking the relevant Project Wiki first, we can move into initial confirmation within a few minutes.

The post-update check also changed.

Before, we manually swept the site after applying updates.
This took more than five hours per site per month in some cases.
Even then, it was difficult to eliminate missed issues such as broken links, broken images, or layout problems.

When checking live sites, finding 5–10 anomalies on a single site was not unusual.
During emergency patch response across multiple sites, that workload piled up quickly.

Now, immediately after an update, we use MONJI+ website anomaly detection & improvement feature to automatically sweep the entire site.

It lists machine-detectable anomalies such as broken links, broken images, layout breakage, and missing tags.
Those findings can then be turned directly into feedback.

Since adopting this workflow, the effort spent on checks has dropped by 80%.
Except for items that only a human eye can judge, missed machine-detectable anomalies have become nearly zero.

Because detection, feedback, post-fix confirmation in Google Analytics, and Wiki records are connected within one project, we can later trace what happened in chronological order:

when it happened, which patch was involved, what issue appeared, and how it was fixed.

---

Notes and limitations

That said, not everything can be left to systems or automation.

Which patch should be applied to which site, and when?
That decision is not something a machine can take over.

If a problem appears in staging, how long should you wait?
At what point should you move forward with production?
How should the client be informed?

These decisions still need to be made by people who understand the site’s situation.

There are also subtle design issues and bugs that only become visible when someone actually uses the site.
Machine-detectable anomalies can be automated, but human review still has its place.

Our approach is to let the system handle discovery, sweeping, and recording.
At the same time, humans keep ownership of judgment and final confirmation.

That balance has helped us reduce the burden during emergencies without handing over the decisions that still require human context.

---

MONJI+, the WebOps platform born from the field

CMS vulnerability response is only one example.

In website operations, small tasks such as checking, contacting, recording, and requesting fixes accumulate every day.

When those tasks depend only on individual memory or scattered notes, everything may look fine during normal times.
But the burden becomes visible all at once during an emergency.

MONJI+, the WebOps platform, was born to solve the challenges we have felt firsthand in the field.

MONJI+ brings the people involved in website operation together into one team, and works across every phase of website operation to solve their challenges.

From the start, we have never aimed to build a “finished product.”

The challenges truly worth facing are in the field of website operation.
That is why we have kept engaging with the real voices from that field.

Taking in each voice one by one, we have continued making updates that resolve small points of friction.
New features have also grown out of the field’s challenges.

Through that accumulation, MONJI+ has become something supported by users across 77 countries.

▼ Learn more about MONJI+ here
https://monji.tech/plus/

A world where the people working in website operation can say, with pride, “I love this work.”
▼ To make that real, we are waiting to hear your voice
https://monji.tech/plus/co-creation/

---

Summary

In CMS vulnerability response, applying the patch itself is not the only challenge.

For agencies managing multiple client sites, the first bottleneck is often identifying which sites are affected and who needs to be contacted.

We consolidated each site’s setup and contact chain into a Wiki, and gathered admin URLs, update runbooks, and related files inside the same project.
That turned what used to be a half-day discovery scramble into a few minutes of checking.

We also standardized pre- and post-update checks through a checklist, and automated the post-update sweep using website anomaly detection.
As a result, the effort spent on checks dropped by 80%, and missed machine-detectable anomalies became nearly zero.

Of course, deciding when to apply a patch and checking issues that only appear through actual use remain human responsibilities.

That is exactly why the parts that can be systematized should be prepared during normal operations.
The preparation that keeps you from panicking in an emergency cannot be created during the emergency itself.