Why We Proactively Took RSVPify Offline In Response to the PHP2Shell Incident

On October 21, 2026, the PHP Foundation released an emergency fix for two critical vulnerabilities in PHP, the programming language that runs roughly 70% of the world's websites, including WordPress, Drupal, and parts of the RSVPify platform. As the Wall Street Journal reported, researchers found the flaw with the help of AI, and it puts up to 70% of the world's websites at risk.

The vulnerabilities, nicknamed PHP2Shell, are uniquely dangerous for a few reasons. They sit inside PHP itself, so every site running an affected version was exposed no matter how well its own application was built. They can allow an attacker to take control of a server without logging in, and to read memory that may hold sensitive information such as passwords. The flawed code had gone unnoticed for more than a decade, and because AI is speeding up how quickly flaws like this become working attacks, the window between disclosure and real-world exploitation is shorter than ever. Cybersecurity agencies in the US and Europe urged companies to act immediately, and websites around the world briefly went offline as their operators raced to patch.

After a morning of interim protections and log reviews, and with no deployable patch yet available, our team made the call to take RSVPify offline while we finished applying the fix.

For RSVPify, the stakes are especially high because of the kind of information our platform holds. Every event on RSVPify carries attendee names, email addresses, phone numbers, and RSVP responses, and many also include ticket purchases, donations, meal selections, accessibility notes, and seating details.

Much of that information belongs to guests who never signed up for RSVPify themselves. They share it because they trust the host of the event, and our customers trust us to keep it safe.

We found no evidence that any customer or guest data was accessed, and RSVPify was back online the same afternoon as the patched software rolled out. The rest of this post explains how we made that decision and what it took.

Why We Chose to Proactively Take Down RSVPify

Taking our platform offline was one of the hardest decisions our leadership team has made. We knew exactly what an outage would mean for the people who rely on us, and we weighed every part of it before acting.

What we weighed

• Live events. Our customers run conferences, executive events, fundraisers, galas, and even major personal events like weddings -- some of which were happening while we're were offline.
• Event planning and management. Hosts preparing for upcoming events could not create events, update registration forms, promote events, or manage their guest lists.
• Communications and payments. Guests would be unable to register, buy tickets, or donate, and activity from our email and payment providers could be interrupted. That affects our customers' revenue and their guests' experience.

What we decided

We never want to put our customers in that position. We take real pride in the infrastructure we have built so that every event, large or small, runs reliably. Even so, keeping the platform running while the vulnerability remained open meant accepting a risk to the attendee and payment data our customers have trusted us with, and that risk was too great.

RSVPify has built its reputation as the industry leader in private events and event data security. Protecting that reputation, and the trust behind it, required a short and painful fix. Given the same choice, we would make the same decision again.

What Was Required

Responding to PHP2Shell meant working on several fronts at once. We had to protect the platform before a fix existed, get that fix into a form we could actually deploy, and check our systems for any sign that something had gone wrong.

Preparing before the patch arrived

Our preparation began on October 20, when PHP gave advance notice of the upcoming security release. Our team checked the software versions running in production, reviewed our exposure, and planned how we would roll out and verify the update.

Early on October 21, we applied a recommended configuration change across our applications and marketing website that reduced exposure to one of the two vulnerabilities. Cloudflare deployed emergency firewall rules, and we worked directly with our Cloudflare team throughout our response. At the same time, we searched our application logs, error reports, and server records for any sign of exploitation.

Why the fix took time to deploy

PHP published the fixed releases on October 21, but a published patch still had to be built into the updated software images our applications run on. We were waiting on the Docker team and our other deployment providers to release complete, deployable builds. Meanwhile, the services that distribute software packages were overwhelmed as organizations around the world rushed to update, which slowed everything down. Our marketing website also needed an operating system upgrade before it could receive a supported, patched version of PHP.

By midday, Cloudflare was reporting exploitation attempts elsewhere on the internet. The interim protections we had in place reduced risk, but they covered only part of the problem, we could not independently confirm the firewall covered every attack method, and our logs could not reliably rule out a successful attack. With no deployable patch available yet, our founder, CEO, and CISO made the decision together to take RSVPify offline.

“Before the PHP patches were released, I called our CEO and founder to make sure we were prepared to take RSVPify offline if necessary. We hadn’t found evidence of a breach, but we couldn’t be confident the temporary protections were enough. We knew a shutdown would disrupt customers, and we didn’t take that lightly. Ultimately, we made the call together. Protecting customer and guest data came first, even if that meant temporarily turning the platform off.”

Corey McCormick, CISO, RSVPify

How customers were affected

For a little under four hours, guests could not access event pages, register, buy tickets, or use check-in, and hosts could not reach their dashboards. API connections were interrupted as well, and customers running events that day had to work around the outage.

Scheduled emails, reminders, and automations kept sending the whole time. Our first status page update said they had been paused, which was incorrect, and we corrected it later that day. The shutdown also interrupted notifications from our email and payment providers that tell RSVPify about delivery and payment activity. Once we were back online, we replayed every missed notification and reconciled payments.

What our investigation found

We found no evidence of unauthorized access to customer or guest data. Our review covered 14 days of application logs, roughly 27 GB of records, along with 30 days of application error reports and the marketing server's PHP logs. We looked specifically for memory-corruption errors, unexpected crashes, and other signs associated with these vulnerabilities. Cloudflare's PHP2Shell-specific firewall rules recorded no matches for our domain during the review period, and server-level checks found no indicators of compromise.

No investigation can rule out every possibility, especially for a type of vulnerability that may leave little trace in logs. That uncertainty is the reason we chose to go offline before seeing any evidence of an attack.

How we protect data every day

The tools that guided this response are part of our regular operations. A few examples:

• Two web application firewall layers, with Cloudflare in front of the platform and AWS WAF inside our hosting infrastructure.
• Intrusion detection through AWS GuardDuty, which monitors our cloud environment for suspicious activity.
• Application logging and error monitoring that help us investigate unexpected behavior and potential signs of exploitation.
• Restricted administrative access through VPN or Zero Trust controls, with single sign-on and multi-factor authentication.
• Regular penetration testing, including AI-assisted tests against our staging environments and independent third-party testing.
• Automated dependency checks that flag known vulnerabilities in the software packages we use.

Our security team also closely monitors vendor security advisories and threat-intelligence alerts, which give us early warning of newly disclosed vulnerabilities and attacks emerging across the internet. These are selected examples, and we use additional tools and procedures that we keep private so they can't help bad actors.

What we're improving

We have already replayed the missed email and payment notifications, reconciled payments, tightened our firewall coverage, and restricted database access on our marketing website server. Our review also identified further improvements we are working on:

• Updating our shutdown process so our email and payment providers know to retry notifications sent while we are offline.
• Deciding in advance which background jobs keep running during a shutdown, so our customer updates describe it accurately.
• Reducing our dependence on public download services during emergency deployments.
• Adding credible reports of attacks elsewhere on the internet to our shutdown criteria, so we can act without waiting for signs of an attack on our own systems.