I always strive to provide sociological insight on this website whenever I can; be it theoretical, methodological, or empirical. After all, the world we inhabit is what we study. So coming up with examples shouldn’t be too difficult, right? Well, it is surprisingly hard to find a real-world example to demonstrate sociological insight. What you need is not just something you experienced the day before; it also needs to feel relatable to your readers, lest they will need a whole contextualization before being able to follow what makes the phenomenon interesting. In addition, whatever sociological insight you wish to explain needs to align with the phenomenon of interest. Society is complicated, and typically, most things that happen around the world can be explained with more than one angle.
That’s why I am so happy about how the stars aligned in this case. Today I wish to talk about PHP2Shell and why that vulnerability is a prime example to understand how Granovetter’s threshold models actually work. I’ll first provide a very brief primer of his conception of threshold models, so if you require an in-depth explainer, I invite you to read his full paper, “Threshold Models of Collective Behavior” from 1978. Then, I provide an overview over what happened with PHP2Shell. You will have heard of this, likely because you suddenly couldn’t access most of your university’s services, and did some research into what the hell was happening. Finally, I explain the core of today’s article; how the way PHP2Shell went down on October 21, 2026, actually resembles a threshold model, and can teach us something about how we should think about it.
Threshold Models of Collective Behavior
Granovetter’s threshold model is surprisingly quick to explain. This is the benefit of many rational-choice-style models in sociology. There’s lots to critique about the fact that it’s only about individuals, and not larger societal structures, but this is an advantage when it comes to comprehensiveness. Granovetter’s threshold models are conceptually so simple that he essentially explains them in the abstract:
The key concept is that of “threshold”: the number or proportion of others who must make one decision before a given actor does so; this is the point where net benefits begin to exceed net costs for that particular actor.
What he is saying here is essentially that we require a set of actors, or individuals. Let’s take 20 people. And now there is some collective behavior we are interested, for example, protesting the room temperature while in a conference meeting. While most people probably think the A/C is set too cold, they vary in how willing they are to interrupt the meeting to complain about the temperature. You will have a bunch of Americans who have never experienced a thing such as a “too cold” A/C, so they are very unlikely to complain. In Granovetter’s terms, their “thresholds” (to jump into action) will be very high. Then you will have a bunch of Germans who are existentially afraid of A/Cs and believe it will make them sick, so they are very fast at complaining. And then you have a bunch of Swedes whose range of lagom1 does not encourage them to complain too fast.
Now, what Granovetter argues in his model is that thresholds do not say anything about the preferences of the individuals. Instead, it says something about what requirements need to be in place before someone actually acts to either save or realize their preferences, in this case their preferred temperature. The intuition here is that people typically are fine with a much broader range of situations than what their “ideal” preferences would actually imply. If my cozy temperature is 19 degrees, I will be fine with a temperature of 25 degrees, especially if I’m not at home but in a third place that may have its own A/C rules. However, the longer I am exposed to this uncomfortable temperature, the more inclined I will be to do something about it. In rational-choice terms, the “benefits” of experiencing a more comfortable temperature start to exceed the “costs” of interrupting the meeting. Threshold models formalize one aspect of this “exposure to”: that some people will need fewer incentives to complain, why others may be much more lenient.
There is a bunch of additional caveats and “ifs” and “whens”, so I recommend reading the full paper, but this should be sufficient for our purpose. What you will notice is that I have already used an example to explain the model. The problem with rational choice models is that they can be very dry and formalistic, so how you will often learn about these models in university is that the teacher will come up with examples. In fact, coming up with examples is one of the primary tasks in preparing theory courses. And this is precisely why I appreciated the PHP2Shell incident: It means I can give you a real-world example instead of some contrived conference room.2
PHP2Shell: A Primer
So let’s dig into PHP2Shell. You might not have heard about the incident by this name, as it was coined only after the fact. What you might have heard, or how you might have learned about PHP2Shell is that your university probably has emailed you telling you that most university services will be shut down for about half a day or a bit longer, “for security reasons.” If you are not (yet, or, any longer) at a university, you may have heard it from news reporting. It even made the national news in several countries.
What happened is actually quite mundane. On October 20, I received an email asking me to provide my preferred dates for a meeting, using a privacy-focused Doodle-alternative hosted by a German organization. However, when following the link, I was greeted with a page telling me that all services of the organization have been suspended “for security reasons” and “until further notice.” Curious as I was, I dug a bit deeper, and quickly stumbled upon a note from the PHP foundation saying that on October 21, 2pm UTC, there will be a security update fixing two critical vulnerabilities. That whole message was merely three sentences long, and that was all we knew publicly at the time.
If you’ve never heard of PHP: It’s essentially a programming language that drives the web. More than two thirds of all websites on this planet run on PHP, including this blog. It’s been around for very long, and it is a pretty robust language that has served me well for at least twenty years at this point. But literally any piece of software, including programming languages, will have bugs. And sometimes these bugs can be exploited to wreak havoc, turning them into critical security vulnerabilities. That is what happened: two bugs have been identified in PHP that affected essentially every PHP release since version 5. When I had seen the notification on the PHP website, these bugs were most likely already fixed, but the PHP team wanted to delay the release of the bug fix a little bit to ensure that all the various IT teams around the world have time to mentally prepare for updating.
Then, on October 21 at ca. 1:30pm UTC, it was time: The PHP team released the updates, and a large wave of updates was run across the global internet in an attempt to patch the security holes before they actually get exploited and lead to issues for millions of internet users.
A detail you should know is that I am currently on a research visit in Helsinki, Finland. 2pm UTC is 5pm local time, which is the end of the work day. Since I have started working very early in the day, I was scheduled to enjoy a good Finnish sauna at this time. However, I took my phone with me, and at 5pm, sitting in a whirlpool in the spa area, I logged in to a server via SSH and ran an update of PHP to patch it. There were a bunch of Fins with me in the area that looked at me with a mixture of amusement and horror for working in the spa.
So, the question is: what prompted me to make this crazy maneuver and take work with me to a free time activity?3 I talked a lot with my colleague about this incident, and realized that I was partaking in a threshold model that crossed my personal threshold.
PHP2Shell as an Instantiation of a Threshold Model
How can we view the PHP2Shell incident as a threshold model? Well, let’s start with me and my preferences to have a baseline. I personally would say that my preferences regarding security and updating are reasonable. Whenever I can update, I will, but not necessarily right away. Sometimes, I give it a day or so, just to wait for a time and place when it is convenient for me to do so (primarily waiting until I am connected to a sufficiently fast Wi-Fi). When it comes to security-critical issues, I tend to be a bit more cautious. Instead of waiting until it is convenient, I assess what the potential impact of waiting would be, and let that decide when and how to update.
In the PHP4Shell case, my assessment of whether it would be good to update changed throughout the 24 hours leading up to the patch release. The first time I learned about PHP2Shell was with the maintenance notice. However, they are Germans and as such probably more likely to be cautious, even when not strictly necessary. So this one organization that has already “reached” its threshold for springing into action was not sufficient to update my assessment. Their “threshold,” in other words, was extremely low.
On October 21 then, things started to move. I received an email from my university that PHP-based services (primarily a bunch of WordPress pages) would be taken offline as a precaution until the PHP version could be fixed. This made me a bit more concerned. The Swedes aren’t known for being pathologically cautious, so if they decide that pulling most PHP-based services offline for several hours, there must be something going on. Next, my colleague found out that the same was true for Helsinki university: Most PHP-based services were taken offline. After that, I received an email from my server provider strongly urging everyone to patch PHP as soon as possible. Finally, I saw even Reuters reporting that apparently most European government websites were being taken down, and with it a large portion of the accessible internet. They did so after security agencies, most notable the U.S. NSA and the German BSI, have issued strong warnings that this security bug was serious and should be treated with the appropriate respect.
This had me thinking: If even security agencies are pushing for it, something must be afoot. So I reconsidered my stance: Was it okay to wait a bit with updating, or is my server among the potential targets for malicious actors to exploit this weakness immediately? The issue here is now the following: My personal websites aren’t that interesting of a goal, because there’s nothing really in the backend that isn’t visible from the frontend. Then I do have a few services that contain sensitive data which are running on PHP. That made me a bit uneasy. However, these services aren’t really “known” on the internet, and also my personal data is probably not as appealing as the data of governments, so I wouldn’t be among the first targets by a long shot. But that server also contains data from other users. A lot of infrastructure of the Zettlr project is hosted there, including a forum. And that’s what then triggered my threshold: While I am not too concerned about me, personally, I have a responsibility to a few hundred people that have some small amount of personal data stored on my server in a vulnerable PHP-based service. And even if that was likely not on the list of valuable targets for hackers, I felt that it shouldn’t matter: it’s other people’s data, and you don’t take chances with that, because these people have to trust you when they give away control over their data.
So I weighed my options. I could’ve just pulled the plug of my server and shut down the web server. That would’ve been the nuclear option that many governments and government agencies across Europe took. A vulnerable PHP installation isn’t vulnerable if it cannot be reached by would-be hackers. But that would’ve also fried a lot of critical infrastructure for Zettlr. Users might’ve been greeted with a firework of error messages when the app tried to check for updates, and the likes. It was very difficult for me to estimate the potential impact of pulling the plug.
The alternative was very simple: Since the PHP developers were likely already in contact with all the major Linux distributions and everyone was on boat, I trusted that, the moment the updates were released, Debian would have them in the package lists. Updating PHP would take a mere 30 seconds — as opposed to several hours of preparation and “postparation” for shutting down the entire server. So instead of wasting a few hours shutting everything down, I decided the minimal impact would be for me to just take my phone with me, and refresh the PHP page to see when the updates are available, and then just run an update asap. Indeed, it took only 30 seconds, and fortunately, the release happened shortly after the spa session began, so for the remainder of the evening, I was phone-free. It still felt somewhat odd, but from a rational perspective, this was the optimal way to resolve my threshold being crossed for everyone involved.
The Bigger Picture
While my position in the entire model is now clear, it makes sense to end this article with a few notes on how the model has evolved across all involved agents. The lowest threshold clearly were held by organizations and individuals who are very paranoid about security on the internet. Especially organization in the free-software movement were likely the ones with the lowest threshold, meaning all it took for them to start springing into action was the release of those few lines of news on the PHP website, written by some volunteer.
That same news post likely also triggered very formal procedures within the security agencies. Here, we aren’t talking about “gut-based” thresholds as in my case, because these thresholds are often legally defined, or at least via formal procedures. Security agencies typically have the mandate to investigate any potential security issue, and then formulate a suggestion for governments on whether to actually act or not. The governments then (which across most of Europe also includes universities) are (typically also legally) mandated to act on this recommendation. And they often decided that the best course of action was to just pull the plug on most services with no warning.4
That, in turn, now crossed the thresholds of a bunch of other actors with no legal mandate to listen to security agencies, but which still thought: “Okay, if half of Europe is going dark now, this must be serious.” Indeed, would you say that governments are overreacting if everyone does it? So more companies decided they should probably do something similar. Some decided to patch PHP right away, some decided to follow the pull-the-plug-strategy. Then, after seeing more services being turned off as a precaution, this likely has also crossed thresholds of others, who might have not seen this as too impactful for themselves otherwise. As you can see, a threshold model heavily depends on time as a chain reaction is set in motion.
At the end, when the patch was released, half the global internet was offline, and in Europe it would remain offline until the next morning. All of that for an update that took about 30 seconds.
And that is how threshold models work.
A very famous Swedish word which roughly translates to “just good enough.” Swedes are the masters of mediocrity. ↩
To be transparent: That example did happen a few years ago, now that I think about it. But I think a security vulnerability is cooler than an A/C. ↩
For my friends who are reading this and want to protest: I know I tend to work too much. But I have always kept a strict spa-work separation, so this was – even for me – an exception. ↩
The most likely reason they all decided to keep their servers offline for almost twelve hours until the next morning, rather than having an incidence response team patch PHP right away, is likely because the release was scheduled for after work across most of Europe, so it was economically cheaper to just put everything down, and update PHP in the morning, when everyone returned to work. That would also explain why U.S.-based services were much less likely to go dark for so long — for them, it was the start of the day. It’s sometimes that simple. ↩