CVE-2026-3784 beat a new #curl record. This flaw existed in curl source code for 24.97 years before it was discovered.

Illustrated in the slightly hard-to-read graph below. The average age of a curl vulnerability when reported is eight years.

https://curl.se/docs/CVE-2026-3784.html

We recently took over an APT investigation from another forensic company. While reviewing analysis reports from the other company, we discovered that the attackers had been active in the network for months and had deployed multiple backdoors.

One way they could regain root access on Linux servers was by adding capabilities to the Python binary, for example:

setcap cap_setuid+ep /usr/bin/python3.12

An attacker can now effectively spawn a root shell over the Python binary. The thing about this technique is that they haven't set a suid bit on a binary, or changed the Python binary. By setting the capabilities, attackers can build powerful backdoors.

I wrote about Linux Capabilities and how to find them on my blog if you want to learn more. [1]

[1] https://dfir.ch/posts/linux_capabilities/

The DWARF debug format is well-known for debugging executables,
but it is also an effective format for sharing reverse engineering information
across various tools, such as IDA, BinaryNinja, Ghidra, and Radare2.

In this blog post, I introduce a new high-level API in LIEF that allows the
creation of DWARF files. Additionally, I present two plugins designed to export
program information from Ghidra and BinaryNinja into a DWARF file.

https://lief.re/blog/2025-05-27-dwarf-editor/

(Bonus: The blog post includes a DWARF file detailing my reverse engineering work on DroidGuard)

The reason I get so annoyed about people pitching LLMs as a way to 'democratise programming' or as end-user programming tools is that they solve the wrong problem.

The hard part of programming is not writing code. It's unambiguously expressing your problem and desired solution. Imagine if LLMs were perfect programmers. All you have to do is write a requirements document and they turn it into a working program. Amazing, right? Well, not if you've ever seen what most people write in a requirements document or seen the output when a team of good programmers works from a requirements document.

The most popular end-user programming language in the world (and, by extension, the most popular programming language), with over a billion users, is the Calc language that is embedded in Excel. It is not popular because it's a good language. Calc is a terrible programming language by pretty much any metric. It's popular because Excel (which is also a terrible spreadsheet, but that's a different rant) is basically a visual debugger and a reactive programming environment. Every temporary value in an Excel program is inspectable and it's trivial to write additional debug expressions that are automatically updated when the values that they're observing change.

Much as I detest it as a spreadsheet, Excel is probably the best debugger that I have ever used, including Lisp and Smalltalk.

The thing that makes end-user programming easy in Excel is not that it's easy to write code, it's that it's easy to see what the code is doing and understand why it's doing the wrong thing. If you replace this with an LLM that generates Python, and the Python program is wrong, how does a normal non-Python-programming human debug it? They try asking the LLM, but it doesn't actually understand the Python so it will often send them down odd rabbit holes. In contrast, every intermediate step in an Excel / Calc program is visible. Every single intermediate value is introspectable. Adding extra sanity checks (such as 'does money leaving the account equal the money paid to suppliers?') is trivial.

If you want to democratise programming, build better debuggers, don't build tools that rapidly generate code that's hard to debug.

Researchers at Harvard Business School and University of Toronto used unique data to quantify the value of open source.

Takeways:

* Supply-side (cost to recreate) is ~$4.15B, but demand-side (value to firms) is $8.8T. Shows massive cost savings & productivity boost from OSS.

* If OSS didn't exist, firms would need to spend an estimated 3.5 times more on software than they currently do. OSS provides a massive, often invisible, productivity boost.

* A tiny fraction of OSS developers create the vast majority of value. Only 5% of developers are responsible for over 96% of the demand-side value

* Firms should not just "free ride" on OSS but actively contribute to the ecosystem, as this is far cheaper than recreating the software themselves.

Source:
https://www.hbs.edu/ris/Publication%20Files/24-038_51f8444f-502c-4139-8bf2-56eb4b65c58a.pdf