DEV Community: Stiven Llupa

I saw a picture on the internet!

Stiven Llupa — Thu, 22 Oct 2026 08:50:40 +0000

Something happened yesterday that I want to talk about: the PHP security release. Let me start by saying, if you haven't updated to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, go do that first. This post will still be here.

There were posts in relevant channels, at least they seemed relevant enough, about an upcoming PHP security release. This was an important one, so the PHP Foundation wanted people to be ready to upgrade, and I assume, not simply treat it as "we will do it when we do it". That part was fine. Several things that happened after it were worrisome, and I want to talk about them.

First, hackers proving the exploit over the internet. The CVE numbers leaked a day early, with a CVSS of 10.0 attached (the real score is 9.2), and a proof-of-concept video went up and came down, but not before it got copied around. This caused panic, and then social media, or bots, or both, started to share how to "fix" this.

Eventually there was the post from CERT-EU itself. Whether it was because of the social media momentum, or because they knew something we did not know, I don't know. But what they actually wrote was: patch immediately, and where that is not feasible, consider isolating internet-facing applications until the fix is in. Somehow that got distilled to "go offline". It was so bad that even governmental services here and there were not working. (Remember this, it is important for later.)

Then came the AI wave. I don't know how to name it exactly, so I am sticking with that. Panicked elephants, end-of-the-world style pictures, the works. And this while other critical security issues were also released yesterday, for example this one in GitLab. That one is an actual CVSS 10.0, unauthenticated, every self-managed version back to 2014, and no workaround. The AI wave propelled the panic and fear, because something really bad is happening in PHP so we all should panic EVEN MORE. How I experienced it: some RCEs are worse than others, so it is totally fine to accept some RCEs, or faulty signatures, as long as we panic over THIS one RCE!

To be fair, the PHP bugs were serious. Unauthenticated RCE is no joke, and patching fast was the right call. But the attention we gave each issue, before we even knew what the issues were, had nothing to do with the actual risk. It had to do with the noise.

Since 2020 or 2021, I have had the chance to do regular security trainings, and in 2023/2024 I also did more blue-team type training. After that, a refresher yearly. I don't want to bore you with the details of my career, but, like, the one thing they teach you all the time is: do not panic, and do not believe anyone that tries to instill a sense of urgency in you. So what did virtually 99% of anyone I know and "saw" online do? Panic.

I don't want to focus too much on the actual release process and how long it took for the patched version to propagate through all the different package registries, or containers, or the other ways of pulling this. I believe yesterday was a learning moment for everyone. What I found interesting were two posts about the "post mortem" of this release.

The first one is from the PHP Foundation. This entire post is excellent if you have not read it. It touches more topics than a simple "there's news". One thing that stood out to me: one of the providers that was part of the coordinated release broke the embargo more than 6 hours before the planned release. (Second thing that is important for later.)

The second post that I highly recommend is from Alexandre Dubois, who is in the security team. Alexandre saw firsthand how "internet points" can change an entire coordinated release schedule. He also showed us that the trending posts about changing our session ini settings were conflating bugs. The flag everyone was sharing belongs to the other CVE, and the stopgap the advisory actually puts first barely showed up anywhere. He mentions there was some good pre-release advice too, but at that point, we the people were just shooting darts in the dark. What we were effectively doing was opening up our deployments to manipulation from unverified sources. (Third important thing.)

Ok, now my main complaint-as-advice from what I experienced on the 21st of October 2026: just because someone on the internet said so, it does not mean it is true has never been more true.

What I learned if I were a malicious actor is that what I need is a good-enough bot farm, probably an insider at places that do not respect embargoes, and I can achieve a lot:

first, I can start a trend so everyone runs around ignoring some other CVE that I have a better grip on exploiting.

second, I can try to get embargoes broken. This gives me access to a LOT of services that simply cannot get a patched version, because they are not in the provider's (offender's) chain.

third, I can even engage in proxy wars by limiting governmental functions, or annoy some population elsewhere and blame it on the followers of the party I do not support.

fourth: probably more, but I don't really like being a red-team player.

So next time: patch, yes. Fast, yes. But read the actual advisory, ask which bug a "fix" is fixing, and when someone tries really hard to make you hurry, that is exactly the moment to slow down.

The Scenic Route to TYPO3 DevDays

Stiven Llupa — Tue, 11 Aug 2026 08:16:24 +0000

Maps gave me two options to the conference venue: walk alongside the highway, or cut through "the park."

Naturally, I picked the park. Who wouldn't with this in its entry?

What Maps called a park was, in fact, a forest 🌲. So there I was, conference-ready, laptop bag slung over my shoulder, nice shoes and all, strolling through actual woods like I was auditioning for a hiking ad. 🚶

Further in, the path was flooded. Someone before me had improvised a bridge out of what I can only describe as twigs (they were, structurally speaking, not twigs, and I chose not to think too hard about that while crossing).

Then, just when I was sure I'd finally reach the venue, the trees opened up onto a cornfield. A full, sprawling cornfield. I stood there for a second, looked around, and just laughed. This is awesome.

And there it was: the conference center, right on the other side.

A colleague and I had been invited over from the Symfony community and TYPO3 has adopted a good chunk of Symfony components under the hood, so the overlap made sense. TYPO3 DevDays itself kept that same energy going: warm, welcoming, genuinely good vibes from start to finish. But the thing that made me think more than the forest, the bridge, or the corn.

It was how many speakers, across totally different talks, kept circling back to the same idea: build for your users. Not for the framework, not for the demo, not for what's technically impressive, but for the actual person on the other end.

Now that the walk and conference has finished, I am stuck with two things. First, how crazy it was to walk through a forest to reach a tech-con 😅 and second, the importance of end user feels like it is always implied, but never really actively worked on. (I am look at you 👀, stake-holders 🧑‍💼)

Defensive Programming can be very easy with Symfony HttpClient

Stiven Llupa — Sat, 28 Feb 2026 18:37:39 +0000

If your app lets users submit URLs that you then fetch, for link previews, webhooks, or RSS feeds, you have a serious security problem waiting to happen.

An attacker can submit something like http://127.0.0.1/admin or http://169.254.169.254 (AWS metadata endpoint) and your server will happily fetch it.

That's called a Server-Side Request Forgery attack, or SSRF.

Symfony has a built-in solution: NoPrivateNetworkHttpClient.

So your code:

class LinkPreviewController
{
    public function __construct(
        private HttpClientInterface $client,
    ) {}

    #[Route('/api/preview', methods: ['POST'])]
    public function preview(
        Request $request,
    ): JsonResponse {
        $url = $request->getPayload()
            ->getString('url');

        $response = $this->client
            ->request('GET', $url);

        return new JsonResponse(
            $response->getContent()
        );
    }
}

Becomes:

class LinkPreviewController
{
    private HttpClientInterface $safeClient;

    public function __construct(
        HttpClientInterface $client,
    ) {
        $this->safeClient =
            new NoPrivateNetworkHttpClient(
                $client
            );
    }

    #[Route('/api/preview', methods: ['POST'])]
    public function preview(
        Request $request,
    ): JsonResponse {
        $url = $request->getPayload()
            ->getString('url');

        $response = $this->safeClient
            ->request('GET', $url);

        return new JsonResponse(
            $response->getContent()
        );
    }
}

It's a decorator, so you just wrap your existing client & no other changes needed. Follow the documentation to set your specific IPs or IP ranges that you want to disallow.

If you fetch user-submitted URLs and you're not using this, you should be.

Watch in on YouTube

Country codes and regional differences

Stiven Llupa — Sat, 28 Feb 2026 09:38:49 +0000

Here's a little-known Symfony trick for apps that need to support Kosovo as a country.

Kosovo uses the code XK, but that's not an official ISO 3166 code. It is what is called a user-assigned code, meaning Symfony Intl component doesn't include it by default.

So when you call Countries::getNames() from the Symfony Intl component, Kosovo simply won't appear.

use Symfony\Component\Intl\Countries;

$countries = Countries::getNames();

isset($countries['XK']); // false

Countries::getName('XK'); // Throws MissingResourceException

The fix? Just set this environment variable in your .env file:

# .env

SYMFONY_INTL_WITH_USER_ASSIGNED=true

That's it. Symfony will now also recognize XK, XKK, and numeric code 983 for Kosovo.

use Symfony\Component\Intl\Countries;

Countries::getName('XK'); // 'Kosovo'

Countries::getAlpha2Code('XKK') // XK
Countries::getAlpha3Code('XK') // XKK  
Countries::getNumericCode('XK') // 983

A one-liner that saves you from building a workaround. Super useful if you're building apps for any region that needs user-assigned country codes.

Stop writing the same regex for #[Route]

Stiven Llupa — Fri, 27 Feb 2026 18:08:10 +0000

Did you know Symfony ships with a built-in class full of pre-defined route requirement patterns?

It's called Requirement, and it lives in Symfony\Component\Routing\Requirement.

Instead of writing your own regex for common route parameters like UUIDs, slugs, date formats, or locale codes, you can just reference a constant.

So instead of this mess in your route attribute:

#[Route('/users/{id}', requirements: [
    'id' => '[0-9a-f]{8}-[0-9a-f]{4}-'
          . '[0-9a-f]{4}-[0-9a-f]{4}-'
          . '[0-9a-f]{12}',
])]
public function show(string $id): Response
{
    // ...
}

You write:

#[Route('/users/{id}', requirements: [
    'id' => Requirement::UUID,
])]
public function show(string $id): Response
{
    // ...
}

Instead of:

#[Route('/blog/{slug}', requirements: [
    'slug' => '[a-z0-9]+(?:-[a-z0-9]+)*',
])]
public function post(string $slug): Response
{
    // ...
}

You write:

#[Route('/blog/{slug}', requirements: [
    'slug' => Requirement::ASCII_SLUG,
])]
public function post(string $slug): Response
{
    // ...
}

It includes constants for all UUID formats, common date, ASCII slugs, and your usual suspects.

Stop rewriting the same regex. Symfony already did it for you.

Watch it on YouTube