Alternatives to Drupal and Hosted WordPress: Ask About the Patch Chain First

Integrators evaluating a move off Drupal, hosted WordPress or a hosted open-source DXP usually arrive with a version of the same argument: the source is public, so attackers can read it, so a closed platform must be safer. It is a tidy story, and the first security lead you tell it to will take it apart.

Something real did change this year, but it is narrower and much harder to argue with. The gap between a vulnerability becoming public and it being exploited has collapsed, and content management systems are where that collapse is concentrated. That is an operational problem about who applies patches and how quickly — not a licensing problem. What follows is what the published evidence supports, what it does not, and the questions worth putting to any platform vendor, this one included.

What changed in 2026

VulnCheck's State of Exploitation report for the first half of 2026, published 28 July 2026, found that content management systems were the most targeted technology category, "accounting for one-third of all KEVs" — known exploited vulnerabilities — which the report calls "a more significant percentage of KEVs than we've seen historically."

The velocity finding matters more than the volume. By VulnCheck's measurement the median time from CVE publication to confirmed exploitation fell from 120 days in 2025 to 80 days in the first half of 2026, and 23.43% of exploited vulnerabilities showed evidence of exploitation on or before the day the CVE was published. For roughly a quarter of them, there was no patch window at all.

CISA's Binding Operational Directive 26-04 is the regulatory answer to that. It supersedes two earlier directives and moves federal civilian agencies to risk-based prioritisation, with remediation timelines driven by four variables: whether the asset is publicly exposed, whether the vulnerability is in CISA's Known Exploited Vulnerabilities catalog, whether an adversary can automate every step of exploitation, and whether exploitation yields partial or total control. The directive's background section names the accelerant plainly: threat actors' "use of AI may further narrow the time defenders have to react between patch release and possible exploitation."

Where those factors line up, the remediation expectation compresses to days rather than quarters. That is the number worth holding on to, because every question below is a version of the same one: can your delivery model meet a clock like that, across every site you run, without you personally being awake?

Is open source the reason CMS platforms are being exploited?

No. This is the part of the pitch that does not survive a room with a security lead in it, and it is better to find that out here.

Take CISA's own Known Exploited Vulnerabilities catalog, which is published as a CSV anyone can download and check without taking our word for any of this. Reading the copy we downloaded on 18 August 2026 — 1,666 entries, matching on the vendor and product fields — the licence model plainly does not sort the field. Proprietary CMS and DXP products are in the catalog: Kentico Xperience has four entries, Sitecore has four, Adobe Experience Manager Forms has one. Open-source projects are in it too: Drupal core has five entries across the catalog's life, WordPress core has two added in July 2026, Craft CMS has four. Anything with a meaningful install base eventually appears. What the catalog does not contain is a pattern where one licence model is absent.

Federal authorisation tells the same story in the other direction. Acquia Cloud — commercial hosted Drupal — has been on the FedRAMP Marketplace since 13 April 2016, is FedRAMP Certified at Class C (Moderate), and carries 27 authority-to-operate or authority-to-use letters. If your security argument is that open source cannot clear government review, the counter-example is one of the most heavily authorised web platforms in the US federal estate, and the reviewer across the table will know it.

So retire the licence argument before you build a bid on it. It is not that it is impolite — it is that it is checkable in about ninety seconds, and being corrected on your opening claim costs you the rest of the meeting.

What does the exploited-vulnerability list actually show?

Something more useful. The Australian Signals Directorate's Australian Cyber Security Centre has published an advisory on a large-scale exploitation campaign targeting content management systems, describing attackers "actively scanning websites for opportunities to deploy webshells, leveraging various vulnerabilities affecting CMS software and plugins."

The advisory publishes the software and CVEs being exploited as a table. Counting the rows in that published table: seventeen entries, of which eleven are explicitly labelled as WordPress plugins — Simple File List, WavePlayer, BerqWP, WPBookit, Ninja Forms, ThemeREX Addons, Breeze Cache, ACF Extended, WPvivid Backup, Gravity Forms and GutenKit/Hunk Companion. The remaining six are Craft CMS, MaxSite CMS, MetInfo CMS, a Joomla content editor, a framework plugin and a payments component.

Two things are worth reading off that table. Not one of the WordPress entries is WordPress core — every one of them is a plugin. And Drupal does not appear in the campaign at all. The entries that are CMS cores rather than extensions are the smaller products in the list.

That is the finding worth taking to a client: in this campaign the attack surface was overwhelmingly the third-party extension marketplace around a mainstream platform, not the mainstream platform itself. On this evidence the core teams of the large open-source projects are not the weak link. The hundreds of independent plugin authors around them are.

The advisory is blunt about the other half of it, and this is the sentence to put in front of anyone who thinks the answer is a better platform: "The vulnerabilities exploited in this campaign are public and known vulnerabilities, with patches available." Nothing in the campaign was novel. The fixes existed. The sites that were compromised were the ones where nobody applied them in time, across a stack that had a lot of components and no single party responsible for any of them.

How many maintainers are in your patch chain?

This is the variable that actually differs between platforms, and it has nothing to do with whether you can read the source.

A site assembled from a core platform plus twenty contributed modules or plugins has, in security terms, twenty-one independent upstream maintainers. Each has its own release cadence, its own disclosure policy, its own definition of "supported", its own bus factor, and its own willingness to ship a fix on a Sunday. Some are funded teams. Some are one person who has moved on. Your remediation clock is the slowest of them, and you do not control any of them.

A single-vendor platform collapses that to one. That is a genuine structural difference, and it is the one claim in this whole area that survives the counter-examples above — because it is a statement about supply-chain breadth and operational ownership, not about source visibility. It also cuts both ways honestly: with one vendor, you have one throat to choke and exactly one party who can fix anything. If that vendor is slow, you have no second option and no community patch. That is the trade, stated plainly.

Who owns the remediation clock?

Ask it contractually, not technically. For each layer of the stack — the operating system, the runtime, the CMS core, every extension, the hosting platform — name the party who is contractually obliged to ship the patch, and the party contractually obliged to apply it to the running site. In most agency and integrator arrangements those two lists do not match, and nobody notices until an advisory lands on a Friday.

If any of your work touches US federal civilian agencies, there is a second-order effect worth pricing before your next renewal rather than after it. BOD 26-04 does not bind contractors on its own — it says so directly: "Unless directed by the governing procurement contract, this Directive does not apply to contractors, but FCEB agencies must review all contracts to determine what modifications are necessary to comply with the required actions of this Directive." That is not an exemption. It is a description of how the clock reaches you: not as a regulation you can decline, but as a contract modification at renewal, attached to work you have already quoted. The directive goes further for platforms outside a FedRAMP boundary, telling agencies they "must work directly with their Cloud Service Providers (CSPs) to ensure that the supporting CSP infrastructure follows the same requirements" — which puts your platform vendor inside the compliance conversation whether or not they have noticed.

This is also where the honest commercial answer differs by contract type, and it is worth being direct about it. On time-and-materials retainers, patch work is billable: remediation labour is revenue, and a platform that removes it removes margin. On fixed-price contracts, managed-service agreements and portfolio arrangements, the same labour is unpriced cost that scales with the number of sites you run. The second group is where consolidating the patch chain changes the economics. If you are in the first group, a single-vendor platform is a strategic decision about where your practice is heading, not a cost saving — and anyone selling it to you as a saving has not read your P&L.

What does a national cyber agency actually recommend?

The ASD advisory's protective guidance is worth quoting rather than paraphrasing, because it recommends a delivery model without mentioning licences at all. Its first recommendation is to ensure website software and plugins are up to date, and within that, verbatim:

"For internet-facing websites, consider using cloud services for which the cloud service provider is responsible for rapidly remediating vulnerabilities on the customer's behalf."

That is a signals intelligence agency describing where remediation responsibility should sit. It says nothing about open or closed source. It says something about who is on the hook — which is the same question as the section above.

Does replacing the platform actually help?

Sometimes, and it is worth being honest about when it does not.

Moving simple brochure sites to a static generator on a CDN genuinely removes CMS attack surface, because there is no application server to compromise. It is a real answer for a real subset of work. It stops being an answer the moment the site needs authenticated users, forms handling, transactions, or editors who are not developers — which is most of the work integrators actually get paid for. The static-site escape route is available for exactly the projects with the least at stake.

The other honest limit: replatforming does not reduce risk if you carry the same architecture across. A new platform assembled from thirty third-party components has the same patch-chain breadth it had before, wearing a different logo. The reduction comes from consolidating who is responsible, not from the migration itself. It is also worth being clear-eyed about what a platform migration is: our own migration page calls it a rebuild, because that is what it is. Integrators can price a rebuild. Nobody can price a surprise.

What WebinOne does here

WebinOne is an AWS-native digital experience platform, formerly Treepl CMS, built by Upgrade Parade Corp for partners who build and operate client sites. Three things are relevant to this specific evaluation.

First, the patch chain is one vendor deep. Platform capability ships as native extensions built and maintained by us — multisite, advanced backup, comments and ratings, custom reports, events, a Zapier integration and others. WebinOne does not publish a third-party plugin marketplace, so there is no contributed-extension ecosystem to inherit. That is the point of the section above, and it is also a genuine functional constraint: where a capability does not exist, extending the platform is a scoped development project with a quote and a delivery date, not an afternoon installing something from a directory.

Second, remediation of the platform and the infrastructure under it is ours, not the partner's. Our published security overview sets out the split in AWS's terms: "AWS operates, manages, and controls the components from the hypervisor virtualization layer down to the physical security of the facilities in which WebinOne operates. In turn, WebinOne assumes responsibility and management of the guest operating system (including updates and security patches) and application software, as well as the configuration of the AWS-provided security group firewall." Backups are described in the same document: WebinOne stores data in Amazon EBS and backs it up via snapshot lifecycle policies every 12 hours.

Third, there is a published incident process rather than an assurance. Our incident response plan names a responsible officer, makes the CIO the incident commander with the CTO as default deputy, defines severity levels and separate containment and communications teams, and commits to reporting the incident and findings to partners within 72 hours of the initial incident report. Ask us when it was last exercised — that is the right question to ask anyone who publishes one, and it is a fair question to ask us.

What WebinOne does not have

Stating this plainly is more useful to you than any adjective we could put in the section above, and it will save you a wasted bid.

WebinOne holds no FedRAMP authorisation. It is not CMMC-certified. It runs in AWS commercial regions, not AWS GovCloud. Sites run inside WebinOne's own AWS account today; deployment into a partner's or a customer's own account is a commercial conversation quoted deal by deal, not a shipped capability you can assume. There is no installable artefact you can place inside your own authorised boundary and patch on your own schedule. Our terms of service also state, on agent isolation, that we apply commercially reasonable measures to isolate agents and data between accounts but do not guarantee that isolation will be absolute. Where the security overview cites SOC and ISO reports, read carefully whose they are: those are AWS's certifications for the infrastructure underneath, not ours for the application above it.

If your bid requires FedRAMP, GovCloud or an on-premise installable with a published patching cycle, this platform does not clear that bar today, and no amount of conversation changes that this quarter. If your portfolio is commercial, multi-site, and carrying its own remediation obligations, the rest of this page is the relevant part.

There is one more thing worth knowing before any single-vendor platform decision, because consolidating your patch chain also concentrates your dependency, and a good procurement team will say so. Our terms of service publish an End of Life Immunity clause: "In case of an unlikely event of the Service being closed or discontinued for any reason, we commit to open-source the WebinOne platform to the level that every Reseller would be able to host their trial and live sites, WebinOne Portal, and SSO service without our support." It is in the contract rather than in a sales deck, which is the only place a clause like that means anything.

Questions worth asking any platform vendor, including us

Bring these to every vendor in your evaluation and compare the answers rather than the marketing.

How many independent upstream maintainers are in the patch chain of a typical site on your platform? Who is contractually responsible for applying a security patch to a running production site, and within what period? What is your published process when a vulnerability in your platform is added to CISA's Known Exploited Vulnerabilities catalog? Where does the platform run, whose account is it, and can it be deployed inside our authorised boundary? What authorisations and attestations do you actually hold, as opposed to those held by your cloud provider? When was your incident response plan last exercised, and what changed as a result?

Ask for the authorisation, not the adjective. A vendor that answers a certification question by describing how seriously it takes security has answered no, and that includes us on the questions where our answer is no.

Answers to those six questions will separate platforms far more reliably than any argument about source code visibility. If you want ours in writing against a specific portfolio, talk to our team and we will go through them site by site as part of a technical assessment. Partners running client sites under their own brand can also read how the reseller model handles operational ownership.