Attackers Stopped Picking Targets, So Mid-Size Companies Are in Range

If your marketing team owns the website, it owns the website's security too, whether or not anyone wrote that down. For a long time that arrangement held up fine at a mid-size company, because breaking into one took skill and patience, and attackers spent both on bigger prizes. AI has made the effort cheap, and the companies that used to be too small to bother with are now just as easy to try as everyone else.

In Part 1 of this series, I covered PHP2Shell and the idea of door count. Since then, watchTowr has reported exploitation of both flaws in the wild. If that news sent your leadership team asking whether the website is safe, there's a fair chance the honest answer started with a pause and ended with "let me find out who handles that."

On a recent Building the Next Web live, Witt Langstaff, Edgar Allan's Solutions Architect and AI/Tech Lead, described the change with a metaphor about an apartment building. A burglar used to walk the halls trying doorknobs one at a time. "Now this burglar might have the ability to check 10,000 doorknobs at once in the whole building and then move to the next one," he said. "He just has to find one that’s unlocked."

Jared Malan, our Technical Director and founder of answer.cloud, spelled out who that hurts. AI is "lowering the bar for these black hat hackers" who may never take on a large organization, "but there's just so many smaller-sized companies that they can really do damage to." 

To keep the metaphor going, large enterprises tend to have a security team watching the hallway, while plenty of mid-market companies just have a marketing manager with admin rights and a very full calendar.

Marketing Took On the Website for Speed. They Inherited a Patch Schedule Nobody Owns

Marketing teams took over their websites for good reasons. Waiting three weeks for IT to publish a landing page is no way to run a campaign, and platforms like Webflow made it realistic for marketers to ship on their own.

The part that rarely gets discussed is the handoff. On the live, I described a pattern we see over and over: marketing wants ownership of the web layer, and IT is relieved to let it go. The IT side of that conversation usually sounds something like "I don't want to support this anymore. I don't want to have to go and run the patch." Fair enough, though somebody still has to run the patch.

What's left is a website everyone uses, and nobody tends. Patch schedules, admin accounts, and the vendor login from a 2022 redesign drift into the space between two departments that each assume the other one has it covered. We've started calling it the office plant problem.

The office plant problem is Edgar Allan's name for a company website that everyone enjoys and nobody is sure who waters. It sets in when marketing takes ownership of the site and IT steps back, leaving patches, admin accounts, and old vendor logins in the gap between the two teams.

Weak Passwords and Stale Access Are the Doors Agents Find First

Witt was blunt about where trouble usually starts in his experience: "Nine times out of ten, that stuff is happening because somebody has a password on the main account that's like password one, two, three." Add the agency whose contract ended two years ago and still has a login, the former employee whose account nobody closed, and the component that hasn't been updated since its developer moved on, and you have exactly the doors an automated scanner is built to find.

The encouraging news is that none of these things takes a security team to fix. Each one takes a person whose job includes checking it: someone who turns on SSO or multi-factor authentication for every admin account, removes access the day a contract or a job ends, and knows which components need patching this month. Just a few tasks over the course of a week.

Jared has seen what it costs when nobody does that work; he speculates hundreds of thousands of dollars on the low end, with longer-term technology improvements potentially costing millions. A friend of his who runs technology for a public organization got hacked, and "it was a nightmare for him for over a month as they figured out what to do." A month of recovery is an expensive way to learn who owned what.

Size Your Stack to the Team You Have

Jared said something on the live that I'd repeat to every marketing leader: "It might be a hard time to be running technology in an organization that does not have full defense capabilities." Most marketing teams don't have those capabilities, and most shouldn't have to hire them. The better move is to run less code that needs defending, because every component your team owns adds a recurring maintenance job, and the cheapest security capability is the one you never need because your platform vendor carries it.

That makes platform choice a staffing decision as much as a technical one. Our comparison of Webflow and AI-native development sums it up in a single row: Webflow manages platform security and uptime with predictable overhead, and on a custom build your team manages dependencies, security patches, and monitoring. Here's how that splits for a marketing-owned site:

The bottom two rows stay with you on any platform, which is why the top four deserve so much attention. If two people on your team touch the website, they can realistically keep up with access reviews and integrations. Asking the same two people to also track patches for dozens of components is how a site slides into the gap.

Whatever Your Team Shouldn't Carry Belongs With Your Platform

The security work your team shouldn't handle should be written into your platform. A managed platform's own security team patches the core, secures the servers, and keeps the site up. On an open-source stack or a vibe-coded build, that work falls to your team or your agency for as long as the site runs.

Agencies build on top of that foundation. The SOW should name who owns what stays on your side, like SSO, admin access, integrations, and custom code, and set response times for urgent fixes. If it also asks the agency to patch the core and watch the servers, your stack needs more upkeep than your team can give it. Before you sign, ask for three things:

• Platform commitments. Your platform's security documentation, SOC 2 report, and uptime SLA, so you know exactly which layers the vendor carries.
• Named ownership. Which of the remaining tasks belong to the agency and which stay with your team, plus an SLA tier for urgent security fixes that sits apart from routine change requests.
• Proof. The agency's own SOC 2 report, since an agency's compliance is separate from the platform's.

On that last point, Edgar Allan is one of the SOC 2-compliant agencies in the Webflow ecosystem, and we share our SOC 2 Type 1 report under a mutual NDA. Our security page covers how we protect client work. Our enterprise Webflow agency checklist walks through the other questions worth asking a partner.

Build Your Security Owner Map This Week

The fix for the office plant problem is a watering schedule with names on it, and you can draft one in an afternoon. List every system the marketing site touches, everyone with admin access to each one, and the single named person responsible for keeping it patched and reviewed:

Every blank cell is a gap, and each gap points to one of three fixes: assign an owner, close an account, or move the task into a vendor contract. If the plugins row runs long, go back to your door count from Part 1, because the fastest way to fill that row is to need fewer entries in it.

This is the same exercise we run with clients when we scope who owns what after launch. If your map ends up with more blanks than names, let's start a project.

AI will try every door at once. Make sure each one has someone’s name on it.