Come To Think of It...

Early Monday, the maintainers of BTCPay Server did something you do not often see from a free open-source project: they told their users to shut their servers down. Unauthorized Bitcoin and Litecoin payments had turned up on a handful of installations, and until the team understood how, pulling the plug was the only safe answer. The investigation has since narrowed the problem to an attack vector targeting instances running version 2.4.1 or older — that release shipped back on July 23 — with version 2.4.7 as the fix, and no confirmed drains among operators already on the current release. The mechanics of the break-in have not been published: which installations attackers reached, how they gained administrative access, and what the total losses amount to are all still open questions. What is already clear is the shape of the story, and it starts with what BTCPay is for. The project exists so merchants can stop paying payment-processor fees: you self-host the checkout, hold your own keys...

Alpine Linux just published a post-mortem that should be required reading for anyone who runs GitLab and thinks a version number is a security policy. On October 20–21, an attacker used a freshly registered account to feed crafted CI configurations to Alpine's GitLab instance, aiming at CVE-2026-97229, a CVSS 10.0 remote code execution flaw in how GitLab evaluates regular expressions in CI config. The attacks crashed GitLab worker processes eight times. In four of them, the exploit got partway through and only failed at the next step. The attacker also downloaded Alpine's GitLab container image — likely to tune the exploit against that exact build. Here's the part that stings: GitLab shipped the fix on October 12, a full week before the attack. Alpine had even upgraded to GitLab 19.3.6 on October 22. And the instance was still exploitable anyway. The reason is that the actual bug isn't in GitLab's own code — it's in Onigmo, the regex engine built into Ruby, whi...

OpenSearch started life as a grudge fork. In January 2021, Elastic had just moved Elasticsearch and Kibana away from Apache 2.0 — officially to stop AWS selling Elasticsearch as a service without giving anything back — and AWS answered by forking Elasticsearch 7.10 and calling the result OpenSearch. Five years on, fresh survey data from the Linux Foundation suggests the grudge has curdled into something more interesting: a project spending its second act trying to prove it no longer belongs to the company that made it. The numbers, supplied to The New Stack by the OpenSearch Software Foundation, trace a slow dilution of AWS. Its share of contribution activity across OpenSearch's repositories has fallen from 91% in the project's first year to 72% in 2025-26, and Amazon-affiliated maintainers in the core repository dropped from 95% in 2022 to 71% today. Adoption tells a similar story: self-managed deployments are outpacing Amazon's managed OpenSearch Service, with 60% of surv...