Recep Emre Erçetin

Technology, products and the occasional rabbit hole. Mostly AI, software and digital systems, plus whatever I learn while building them.

[Recep Emre Erçetin @reercetin]

I’m Recep Emre Erçetin. I work across technology and product, mostly where strategy, design and technology meet. I tend to see software, AI, user experience, product development and digital systems as connected parts of the same world rather than separate disciplines.

That’s pretty much what I’ll be sharing here too: things I know, things I’m testing, things I’m building, things I’m learning, and my take on new technology as it shows up. Sometimes that means spending days testing a feature. Sometimes it means following a new tool way too far down a rabbit hole just to understand what it can actually do.

One of the things I’m especially interested in is how AI fits into software, UX/UI, product development, project development, analysis, marketing and other production workflows. I’m much more interested in using things than talking about them from a distance. I want to know where a technology genuinely helps, where it falls short, where it’s being overhyped, and what changes once you actually put it to work.

So you’ll probably see a mix of working systems, product ideas, experiments, workflows, tools I’m using, and personal opinions on whatever is happening in tech. I don’t expect everyone to agree with me on everything. In fact, some of the best conversations usually start when people see the same thing differently.

I also want to make more of what I build and share accessible globally, while getting to know founders, developers, product people, designers and other builders working in similar spaces around the world. I don’t really see this as a place where I just publish things and leave. I’d rather it become somewhere I can meet interesting people, exchange ideas and keep learning from others too.

AI in my professional work is a separate subject. Depending on the project, I may use it as part of research, analysis, development or production workflows. In some projects, AI is part of the product or system itself. I don’t see AI as an identity on its own. To me, it’s one of the tools that can significantly improve how we build, analyze and solve problems when it’s used in the right place.

A quick note on my content, because apparently this needs saying in 2026 😄 I do use AI to speed up research and as an editorial tool. But the experiences, opinions, mistakes, tests and conclusions are mine. If I say I tested something, I tested it. If I say I think something, I actually think it. AI can help me research faster, organize information and express something more clearly, but it can’t live my experiences, form my opinions or create them for me. So no, my content isn’t generated from someone else’s experience. The ideas and experiences are mine. AI is simply part of the editorial process when it’s useful.

One other small thing about this space. Disagreement, criticism and debate are completely fine with me. They often lead to the most interesting conversations. But if I see insults, bullying, personal attacks or someone deliberately making another person uncomfortable, I’ll hide and block without much ceremony. That applies whether it’s directed at me or at someone else in the conversation. If someone takes the time to read something I wrote or join a discussion here, I want them to be treated with basic respect. Life is difficult enough already. I don’t see that as censorship. I see it as deciding what kind of interaction I’m willing to host in my own space. Different opinions are welcome. Disrespect isn’t. 🙂

So if you’re into technology, products, AI, software, digital systems and the occasional rabbit hole, we’ll probably have something in common here.

[Recep Emre Erçetin @reercetin]

“You can build and launch a product with a $20 AI subscription.”

Fine. But who taught people what happens after launch?

After PHP2Shell, a critical GitLab patch, and new Node.js security fixes, I wish the people making those promises were as loud about maintenance and responsibility as they are about how quickly AI can generate an app.

I'm not against AI development. I use AI extensively in my own work. It has genuinely changed how quickly we can move from an idea to working software.

But a working demo and a production-ready product are very different things.

A product has an architecture, dependencies, a runtime, infrastructure, access controls, stored data, backups, deployment processes, logs, updates, and sometimes real people trusting it with their information.

When a critical vulnerability appears, somebody has to know what runs where, which versions are affected, who controls the server, whether a WAF rule is only temporary mitigation, how to test a fix, and whether the patched code actually reached production.

A prompt doesn't take ownership of those decisions. Neither does a subscription.

And there's evidence that code generation and secure engineering are not the same skill. Veracode's 2026 GenAI Code Security Report found known vulnerabilities in roughly 44% of its tested AI coding tasks. That's a benchmark result, not a claim that 44% of live AI-built apps are vulnerable.

The 2026 Stack Overflow Developer Survey offers another reality check: 48% of respondents said they trust AI output when they can easily verify it. Just 6.6% said they trust it even for important work decisions.

I spent part of this week checking sites I maintain and asking a hosting provider for precise patch confirmation. Even with experience, determining what a provider actually deployed can be harder than receiving a reassuring answer.

Now imagine someone who was told that a few prompts, a monthly subscription, and a deploy button were all they needed to run a digital business.

I don't blame beginners for wanting to build. Making technology more accessible is one of the best things AI has done. What frustrates me is the content that sells confidence without explaining responsibility, then goes quiet when the difficult part begins.

And to be clear, these PHP, GitLab, and Node.js flaws weren't caused by people using AI to build apps. They expose the operational reality that every shipped product inherits.

If you teach people how to create with AI, teach them how to maintain, secure, test, and update what they create. Explain the limits, the costs, and when they need experienced help.

A $20 subscription buys access to a tool. It doesn't buy a secure architecture, a maintained production environment, or accountability for the people using your product.

Making software easier to build is progress.

Selling the illusion that building it is the whole job is reckless.

[Matthew Prince 🌥 @eastdakota]

Some stats on #php2shell. In the 10 hours before it was publicly announced, across the @Cloudflare network we saw thousands of attempts to exploit it. That jumped to tens of thousands in the 45 minutes post announcement, hundreds of thousands within 2 hours, and millions now.

[Piyush Sachdeva - ReelDrop #1 Instagram GrowthTool @techie_piyush]

🚨 THE INTERNET BROKE TODAY 🚨

Oct 21, 2026 will go down in history

1. eMudhra : Private key was literally "4". 8 keys forged ANY website for 17 months. 60M+ certs at risk.

2. SBI CONFIRMED. 3,897 customers' mobile, DOB, address + loan data found on dark web.

3. Rajasthan Police 🇮🇳ALLEGED hack. Group claims 70,000 identity records + 59,460 numbers for sale. Unverified.

4. php2shell [9.2] Unauth RCE in PHP. 70% of the web. WordPress, Drupal, Laravel. CISA: Patch or GO OFFLINE.

5. GitLab [10.0/10] PERFECT SCORE. Unauth RCE, no login needed.

6. Node.js [CVE-2026-111497] Brotli decoder RCE + TLS bypass. 10 CVEs patched today. Also blocked eMudhra.

7. Railway BREACHED TODAY. Env variables decrypted. Your API keys & DB passwords exposed. Rotate all.

8. OpenCode BREACHED. OpenAI, Anthropic, Google API keys exposed for Console users. Distillation attack. Bills run up in $$$$.

9. LiteLLM PyPI v1.107.0 was MALWARE today morning. Steals credentials + backdoor.

10. Plex2Shell ACTIVELY EXPLOITED. Hackers installing cryptominers LIVE. CISA KEV, deadline Oct 23.

AI found the bugs. AI is exploiting them. Humans can't patch fast enough.

Patch. Rotate. Revoke. Update.
RT to save someone's server ♻️

#CyberSecurity #DataBreach #India #php2shell

[Recep Emre Erçetin @reercetin]

PHP2Shell, GitLab, and now Node.js. Three security stories in roughly 24 hours. 😅 But the Node.js release reveals a different problem: updating application dependencies doesn't necessarily mean the runtime actually serving your users is secure.

On October 21, the Node.js project patched 10 vulnerabilities across its supported 22.x, 24.x, and 26.x lines, including four rated HIGH.

The standout is CVE-2026-111497: an out-of-bounds write in the Brotli decoder that can permit remote code execution. The release also fixes TLS hostname verification bypasses, a DNS input validation flaw, and a bug that can cause supposedly random values to repeat across processes created from certain startup snapshots.

These aren't just problems in an npm package you can replace. They reach into compression, networking, cryptography, and the runtime itself.

An important distinction: a vulnerable Brotli decoder doesn't mean every Node.js website is automatically exploitable. Exposure depends on whether attacker-controlled compressed data can reach the affected decoding path. But uncertainty about that path isn't a reason to ignore the security update.

The fixed versions are:

Node.js 22.23.4 (LTS)
Node.js 24.22.1 (LTS)
Node.js 26.12.1 (Current)

Here's where I think teams need to be more careful.

Running npm audit, updating a lockfile, or seeing "Node 24" in a dashboard doesn't prove that the production process is using 24.22.1.

Check the version in the environment actually running your app. Rebuild outdated container base images, redeploy and restart processes, review serverless and managed runtimes, and check CI environments. For unsupported Node versions, plan a move to a maintained release line.

Then confirm the deployed runtime, not just the version on your laptop.

A WAF can provide additional defense, but it doesn't repair an unsafe decompression library or fix certificate verification inside your application.

And if a provider manages the runtime, ask what exact patch or backport has been deployed and how that was verified. "Updates are handled" isn't the same answer.

After my own security checks and conversations with a hosting provider this week, that distinction feels particularly important.

One detail matters for the timeline: Node.js announced this planned security release on October 14. Its timing alongside PHP2Shell and GitLab doesn't establish that the incidents are connected.

I don't want every new CVE to become another panic post. I want it to become a better operational habit.

Software quality isn't finished when the UI works, the tests pass, or the app goes live. It includes knowing what your software runs on, who maintains that layer, how quickly it can be patched, and whether the fix has actually reached production.

The version in your repository is a plan. The runtime in production is the reality.

[Vercel Developers @vercel_dev]

Node.js Security Advisory: a high-severity RCE flaw in Node's Brotli decoder affects Node.js 22, 24, and 26.

Vercel WAF rules are live for every project and block known exploit patterns.

https://t.co/JtfEshHnOC

[Recep Emre Erçetin @reercetin]

A useful contribution amid today's PHP2Shell chaos. 🙌

@horia_nita built a free website checker, shared by @pilvar222. I tested the sites I maintain and it flagged no issues. A relief, but not a security guarantee. 😅

🔎 https://t.co/fqdxsoRZcu

Aikido is clear: a clean result doesn't prove your PHP runtime is patched. Verify the actual fixes with your hosting provider. Only test sites you own or are authorized to assess; deeper checks may disrupt PHP workers.

They've also released free PHP images with backported fixes:
https://t.co/jzqHMCqcFE

Credit to the people putting practical tools in everyone's hands. 👏

[Recep Emre Erçetin @reercetin]

@CrashCarlito That's precisely what I covered in the post. I already asked my hosting provider about patch status, backports, and server-side protections. I received generic assurances, not verifiable patch details. That's the distinction I'm highlighting: reassurance isn't verification.

[Recep Emre Erçetin @reercetin]

Today I checked three WordPress sites after the PHP2Shell disclosure. WordPress, themes and plugins were current. Sucuri scans showed no findings, and I already had complete backups. Then I got to the part I couldn't update myself: the PHP runtime on shared hosting.

The two vulnerabilities, CVE-2026-109618 and CVE-2026-109619, are rated 9.2 under CVSS v4.0. They're in PHP itself, not in WordPress. One involves corrupted internal state when an out-of-memory condition interrupts request initialization. The other involves request data being freed while references to it survive, allowing stale state to be used by a later request in the same worker. These are memory and lifecycle problems, which is very different from finding an insecure plugin endpoint.

The distinction matters because a demonstrated attack path can be triggered while PHP is still processing a request, before the application's authentication or permission checks run. In that scenario, an updated WordPress installation cannot prevent the vulnerable code from executing. The exact exposure also depends on the server setup; Apache mod_php, PHP-FPM and other PHP runtimes are not identical environments.

PHP has released fixes in 8.5.12, 8.4.27, 8.3.36 and 8.2.35. But the newest version I could select in my hosting panel was 8.5.11, and customers on this shared plan cannot install PHP packages themselves. That doesn't automatically prove the server is vulnerable. A provider may have applied a backported patch, and the version displayed in a control panel may not tell the full story. I need confirmation of the actual runtime and its security patch level, not a reassuring label on a dashboard.

This is where I changed from checking WordPress to checking responsibility. I reviewed what I could access, made sure the backups were available, and opened a technical support request asking for the patch status, any backport details, server-side mitigations and an update plan. I have no evidence that these sites were compromised. Equally, a clean Sucuri result isn't evidence that a memory-safety issue in PHP has been fixed.

Cloudflare has deployed WAF protections for PHP2Shell, which is useful for sites behind it. But WAF coverage, plugin scanners and temporary PHP settings are layers of risk reduction, not substitutes for patched runtime code. Some of the suggested mitigations also have to be applied at the server level before request parsing, followed by worker restarts. Editing a WordPress file or guessing at a .user.ini setting isn't the same thing.

I don't expect a hosting provider to complete every emergency rollout within minutes of disclosure. I do expect the provider to know which packages are running, whether the fixes are present, and how to communicate that to customers who have no root access.

This has changed one of the things I look at when evaluating hosting. Price, uptime and performance are easy to compare. The ability to verify an urgent security fix when you can't deploy it yourself is harder to see, but it matters just as much once a real incident is on the table.

[The Hacker News @TheHackersNews]

🚨 CRITICAL: GitLab flaw (CVSS 10.0) affects 12 years of releases.

CVE-2026-110264 could allow unauthenticated remote code execution on self-managed servers.

Read - https://t.co/frrfCwYlgp

[Recep Emre Erçetin @reercetin]

@FrontlineTalks Not yet. I checked three sites, but the provider I contacted only gave general assurances about CloudLinux and routine updates. No exact patch/build confirmation or PHP SAPI details. That's exactly my concern: being told security is handled isn't the same as verifying it.

[Recep Emre Erçetin @reercetin]

As if PHP2Shell wasn't enough for one day... now GitLab. 😅

GitLab confirms CVE-2026-110264 (CVSS 10.0), an integer-overflow flaw that could allow unauthenticated remote code execution under certain conditions. Affected self-managed versions date back to GitLab 7.0 (2014).

GitLab and GitLab Dedicated are patched. If you run self-managed GitLab, install the security update immediately and verify deployment.

Another reminder: security is ongoing maintenance, not a one-time setup.

[Recep Emre Erçetin @reercetin]

PHP2Shell isn’t just a PHP problem. It’s a reminder of how easily we confuse security with the assumption that someone else has it covered.

Two critical flaws in PHP’s core were disclosed on October 21. Under vulnerable conditions, they can allow unauthenticated remote code execution. This isn’t a WordPress plugin bug, and replacing a CMS wouldn’t magically solve a vulnerable runtime.

What unsettles me most isn’t only the flaw itself. It’s what happens between disclosure and a verified fix.

During checks on websites I maintain, I contacted my hosting provider with specific questions about the affected PHP environment and the patches being deployed. I received broad assurances about CloudLinux, routine updates, and infrastructure protection. What I didn’t receive was a clear confirmation of which relevant fixes had actually reached the environment.

That doesn’t prove the server was unpatched. But “we handle security” and “these CVEs are fixed in the runtime serving your application” are two very different answers. Customers shouldn’t need to guess.

CloudLinux’s own guidance makes an important distinction: its Imunify360 WAF rules can block known attack patterns, but they’re an interim mitigation, not a complete fix. A firewall, TLS, a hardened CMS, and a patched PHP runtime each solve different problems. Security tools are layers, not interchangeable guarantees.

Cloudflare also deployed PHP2Shell WAF protections across Free and paid plans, introducing request-and-response analysis to help detect exploitation and prevent data exposure. Valuable defense at the edge, but Cloudflare itself says to patch PHP and keep WAF enabled. Neither replaces the other.

There’s a deeper issue, too. The PHP Foundation says signs of one underlying problem were identified in 2024. Difficult compatibility decisions, limited resources, and delayed decisions held up a fix. AI-assisted researchers later helped demonstrate the real-world exploitation risk. Discovery is getting faster; patch engineering, distribution, and accountability still have to keep up.

And the scrutiny doesn’t end at release. A research screenshot now alleges three exploit paths persist on PHP 8.5.12. I couldn’t independently verify those post-patch results, and PHP officially lists 8.5.12 as fixed for the two CVEs. A claim worth investigating isn’t proof that the official patch failed. That’s precisely why verification matters.

We’ve seen public services temporarily taken offline as a precaution. For an exposed, unpatched system, isolation may be the responsible emergency decision. But taking services down cannot become our long-term security strategy.

And I don’t think the answer is to blame PHP, WordPress, or any one CMS. A custom-built application can fail just as badly if nobody owns dependency updates, runtime patches, infrastructure maintenance, testing, and incident response. Mobile products have backend infrastructure and dependencies, too.

A digital product isn’t high-quality simply because it looks polished and works today. Security is part of product quality and ongoing maintenance, not a checkbox at launch.

Hosting companies, platform operators, developers, and product owners all have responsibilities. Service teams need current knowledge and the ability to give technically meaningful answers, not just reassuring templates.

AI can help defenders find and fix vulnerabilities. It may also reduce the effort needed to find and exploit them. That makes the time between discovery and verified remediation even more important.

My takeaway from today is simple: don’t ask only whether you’re “protected.” Ask what is protected, against which risk, who is responsible, what has been patched, and how that was verified.

Security isn’t a promise. It’s an ongoing, shared responsibility backed by evidence.

[Brayden @BraydenWilmoth]

One-click mitigation for php2shell vulnerability:

If you have Cloudflare in front of your PHP website, please login to the dashboard and click this button to make sure you are protected.

https://t.co/KywdLV8TK7

This reduces your risk but doesn't fix the vulnerabilities in PHP. We recommend updating PHP to a patched version.

[Dane Knecht 🦭 @dok2001]

PHP sites behind Cloudflare already have an initial set of WAF rules deployed for the known exploit vectors in these vulnerabilities. The rules are available to all customers, including free.

We are seeing early attacks emerging and are updating mitigations as new vectors show up.

This is a STOPGAP only. Patch as soon as @ThePHPF releases the update at 14:00 UTC today.

[The PHP Foundation @ThePHPF]

We have posted more information about today's security releases, including the sequence of events that led to the discovery, how the PHP security team is improving their processes, and what we need from you to continue this critical work. #php #security https://t.co/gbGTmk7yh1

[The PHP Foundation @ThePHPF]

The PHP security team is giving advance notice: Upcoming security release Wed, Oct 21st 2026, 14:00UTC, two critical vulnerabilities, both rated CVSSv4 9.2.

PHP users are encouraged to prepare to update. Earlier release if details become public or active exploit evidence.

[Recep Emre Erçetin @reercetin]

WordPress has now issued an urgent warning about PHP2Shell, and there's an important detail that every WordPress administrator should understand: updating WordPress itself will not fix these vulnerabilities. The problem is in PHP, and WordPress has explicitly confirmed that no core update is required or planned for this issue.

Earlier today, most of the discussion was about temporary protections while waiting for PHP's security release. That situation has changed. The patches are now available, so the priority should shift from temporary mitigation to verifying that the PHP runtime actually serving your website has been fixed.

PHP2Shell involves CVE-2026-109618 and CVE-2026-109619, both rated 9.2 under CVSS v4.0. The first involves corrupted internal state during out-of-memory handling, while the second involves stale references to memory that has already been freed. These are PHP runtime vulnerabilities, not weaknesses introduced by a particular WordPress theme or plugin.

What makes the situation especially serious is that a demonstrated attack path can be triggered during PHP's request processing, before WordPress authentication, plugin-level validation or application security checks have an opportunity to run. Depending on the server configuration, simply having an updated CMS doesn't prevent the underlying vulnerability from being reached.

The corrected PHP versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Sites running older or vendor-maintained builds need to verify whether the relevant security fixes have been backported. A version number displayed in a hosting panel doesn't necessarily tell the whole story.

I've already checked three WordPress websites I oversee today. WordPress core, themes and plugins were current, Sucuri scans showed no suspicious findings, and complete backups were available. That's useful information, but none of those checks proves the PHP runtime has been patched. In my shared hosting environment, the newest selectable PHP version was 8.5.11, and I don't have permission to install server-level updates. I've therefore requested technical confirmation of the actual patch status from the provider.

Cloudflare has also deployed WAF protections for PHP2Shell, which adds a valuable defensive layer. Temporary PHP configuration changes may reduce specific attack paths as well, but neither approach replaces a corrected runtime. Even a clean security scan cannot establish that a PHP memory-safety vulnerability has been eliminated.

I think the most useful lesson from today's disclosures is that website security doesn't end at the CMS dashboard. You can maintain every component you control and still depend on an infrastructure provider to resolve a critical vulnerability underneath your application.

The patches are available. Now the important question for site owners, developers and hosting providers is whether those fixes are actually running on the servers handling their traffic.

[Recep Emre Erçetin @reercetin]

Good morning, everyone! Hope your code is bug-free, your designs need no revisions, and your ad campaigns stay perfectly optimized 🙏☺️.

My day is a little different. I feel like a commander rallying the troops and boosting morale before battle 🤣. I haven’t taken a proper break in ages, and today’s workload is finally lighter. So I’m giving my AI team their assignments, stepping back to rest, and planning to play lots of games.

I’ll report back tonight on how it all went 👍☺️ …

[Recep Emre Erçetin @reercetin]

You could come up with the best idea in the world, but if you can’t plan it properly and turn it into a project, it won’t get anywhere.

You could put together the best project plan in the world, but if the experience isn’t built around the people who’ll actually use it, you still won’t get results.

You could create the best user experience in the world, but if you can’t deliver it through the right interface, it still won’t succeed.

You could design the most beautiful interface in the world, but if you can’t code it properly and build it on the right architecture, you’ll end up with something that looks beautiful but doesn’t actually work.

And even if you get every single one of those things right, if you can’t market what you’ve built, you can still fall short. That’s why having the right team matters so much. And if you’re doing it on your own, you need to be equipped to think and work like a team. Otherwise, success becomes almost impossible.

At the heart of all of this is something we sometimes forget: people.

Whatever you’re building, whatever you’re doing, remember that you’re doing it for another human being. Even something as synthetic as a digital product can only build a real connection with its users when that awareness is there.

You could be the best analyst in the world, and there would still be things even the data can’t fully explain. Feelings are one of them.

There’s so much more depth to this than I can fit into a single post. But if I could sum up what I mean, it’s this: no matter how digital our world becomes, and no matter how much of our lives and work happen in that world, success and happiness still have their roots in something deeply analog.

And I think it’s incredibly important to live without losing sight of that.

[Recep Emre Erçetin @reercetin]

Personalization isn't always about collecting more data. Sometimes it's giving people control over how they use a digital product: read, listen, search, or speak, depending on their time and context. Making those choices feel effortless is a product, UX, and engineering challenge.

Think about the same person using the same service in different situations. They might read an article at their desk, listen to it with headphones during a commute, adjust playback speed, search by voice when their hands are busy, or type a question and find the right section in two taps.

None of this requires treating every visitor as a different demographic. It requires recognizing that people's circumstances change, sometimes within the same day.

And there's evidence behind the broader expectation. Qualtrics XM Institute's 2025 report found that 64% of surveyed consumers preferred buying from companies that tailor experiences to their needs. Yet 53% were very or extremely concerned about personal data privacy. Those are consumer preferences, not proof that any particular feature will succeed.

The W3C also points out that text-to-speech benefits not only people with disabilities but people who prefer listening or need to multitask. That's an important reminder: an accessibility-minded choice can improve everyday flexibility, too.

Of course, adding options isn't automatically good UX. If voice search adds delays, playback loses its place, permissions are confusing, or the experience slows down on a modest phone, we've simply moved the friction somewhere else.

That's where product decisions become engineering decisions: which functions actually matter to this audience? Which architecture and technologies fit the browser, device, network, privacy requirements, and operating costs? What happens when speech recognition isn't supported? Can someone switch back to typing without losing progress?

I usually approach those choices through a balance of quality, delivery time, performance, and cost, rather than chasing the most impressive feature list.

Across projects I've worked on, I've seen encouraging movement in heatmaps and time on page, alongside improvements in search visibility and AI-driven discovery as experiences evolved. But I wouldn't claim a specific interaction feature caused all of that. More time on a page isn't necessarily success if someone is struggling to find an answer.

I'd rather check whether people complete the task, find what they need faster, and actually choose to use the options we've built.

For me, thoughtful digital product development is about making people feel that their time, preferences, and circumstances were considered. The best technology decisions are often the ones they barely have to think about.