Team IT Security - 📰 Alle Kategorien

CVE-2026-5349 | Trendnet TEW-657BRM 1.00.1 /setup.cgi add_apcdb mac_pc_dba stack-based overflow

Sun, 26 Jul 2026 11:51:00 +0200

A vulnerability marked as critical has been reported in Trendnet TEW-657BRM 1.00.1. The affected element is the function add_apcdb of the file /setup.cgi. The manipulation of the argument mac_pc_dba leads to stack-based buffer overflow. This vulnerability only affects products that are no longer supported by the maintainer. This vulnerability is documented as CVE-2026-5349. The attack can be initiated remotely. Additionally, an exploit exists. The vendor confirms, that "[t]he product in question (...) has been discontinued and end of life since June 23, 2011, that is more than 14 years ago. We no longer provide support for this product, so we are not able to confirm the vulnerabilities. We will make an announcement on our website's product support page and notify customers who registered their products with us."

CVE-2026-5350 | Trendnet TEW-657BRM 1.00.1 /setup.cgi update_pcdb mac_pc_dba stack-based overflow

Sun, 26 Jul 2026 11:50:58 +0200

A vulnerability described as critical has been identified in Trendnet TEW-657BRM 1.00.1. The impacted element is the function update_pcdb of the file /setup.cgi. The manipulation of the argument mac_pc_dba results in stack-based buffer overflow. This vulnerability only affects products that are no longer supported by the maintainer. This vulnerability is reported as CVE-2026-5350. The attack can be launched remotely. Moreover, an exploit is present. The vendor confirms, that "[t]he product in question (...) has been discontinued and end of life since June 23, 2011, that is more than 14 years ago. We no longer provide support for this product, so we are not able to confirm the vulnerabilities. We will make an announcement on our website's product support page and notify customers who registered their products with us."

1,500 curl authors

Sat, 25 Jul 2026 16:32:52 +0200

It takes a village to make curl. A rather big village. I have not been a solo maintainer of curl for a long time and I don’t even do half of the commits anymore Since today, the curl git repository holds the accumulated efforts from 1,500 separate and named individuals. Only 4.5 years since we … Continue reading →

Linux Foundation Launches Akrites To Coordinate AI-Driven Open Source Security

Sat, 25 Jul 2026 10:12:54 +0200

BrianFagioli writes: The Linux Foundation has announced Akrites, a new initiative to coordinate vulnerability disclosure and remediation for critical open source software as AI dramatically speeds up vulnerability discovery. Founding members include AWS, Google, Microsoft, OpenAI, Red Hat, NVIDIA, IBM, Cisco, JPMorganChase, and others. Akrites will provide a shared Security Incident Response Team (SIRT), a standardized coordinated vulnerability disclosure process, and act as a "maintainer of last resort" for abandoned but widely used packages. The goal is to reduce duplicate reports, avoid conflicting patches, and help upstream maintainers address vulnerabilities before they can be exploited. As AI makes it easier to find security flaws, can a coordinated industry effort help protect open source, or does it risk giving large corporations too much influence over the ecosystem? "Akrites is the largest coordinated effort in history to create systems and deploy tooling that leverages the collective power of the community to make everyone safer," the Linux Foundation said in an open letter. "Akrites participants will contribute engineering resources; work to build and ship fixes; or fund the engineers who do. Some companies have contributed mightily already. The reality is, collectively, we need to contribute more."

Read more of this story at Slashdot.

Rust Will Help Linux Succeed and Makes Coding Fun, Says Greg Kroah-Hartman

Sat, 25 Jul 2026 10:12:26 +0200

ZDNet reports on June's Open Source Summit India 2026 in Mumbai, where Linux stable kernel maintainer Greg Kroah-Hartman gave a talk titled "Rust and Linux: How the Rust Language is Going to Help Linux Succeed." Kroah-Hartman said in his keynote that "the [Linux] kernel is moving toward Rust. Git is moving toward Rust. Lots of projects are starting to move toward Rust." He didn't always feel that way. Kroah-Hartman added, "A number of years ago, when a friend of mine said, 'Ah, you got to try this new language. It's called Rust.' I was like, 'What? No, C is great.' His friend continued, "'No, no, no! It makes programming fun again.' I'm like, 'Nah, programming is fun in C.' He was right. I should have done it then. Rust is actually fun. It makes programming fun. It takes a lot of stuff away from having to worry about the compiler, which can fix a lot of your problems for you, and it makes code a little bit better." So, Kroah-Hartman has moved from being a Rust skeptic to one of its strongest champions inside the kernel. He now regards Rust as a permanent part of Linux, not an experiment. His case is straightforward: Rust's ownership and type system can eliminate most of the "stupid little tiny things" that dominate kernel Common Vulnerabilities and Exposures (CVEs), while making life easier for overworked maintainers. "Rust," in short, "makes my life so much easier...." In India, he said Linux sees "about 13 CVEs a day" and has been running at "almost nine changes an hour" for a decade or more. Most of those vulnerabilities, he argued, are not exotic attacks but simple C mistakes — unchecked pointers, forgotten unlocks, and sloppy cleanup paths: "This is what we're fixing 13 times a day. Small, trivial, little bugs like this all the time.... I've seen every CVE the kernel has done in the past 25 years. I think 80% would be gone, just because they would be caught by Rust." The remaining 20% are the logic bugs he'd prefer to focus on...." Moreover, Rust is becoming the default for new work in key subsystems. "New drivers for some subsystems are only going to be accepted in Rust...." he said. Binder, the Android IPC mechanism at the heart of billions of devices, now has parallel C and Rust implementations in the kernel. The C version "will go away soon," leaving the Rust version "as the bedrock of all Android devices going forward."

Read more of this story at Slashdot.

The Rust Programming Language Blog: The many journeys of learning Rust

Sat, 25 Jul 2026 08:37:24 +0200

This is another post in our series covering what we learned through the Vision Doc process. We previously described the overall approach and what we learned about doing user research, we explored what people love about Rust, dug into what it takes to ship safety-crticial Rust, and described some of the major challenges that people face when using Rust.

In this post we walk through what folks have found on their journey to learn the Rust programming language with ups and downs covered.

As a disclaimer, LLMs (Large Language Models) come up in this post because our interviewees brought them up. We're scoping discussion to their use as a learning tool, covering research and example generation, not broader questions about AI (Artificial Intelligence) in software development.

Many paths to needing Rust

The interviews surfaced several different paths into Rust: curiosity, embedded work, job-market pressure, organizational adoption, and reassignment after a team or company chose Rust. That last path matters because many learners are not evaluating Rust from a blank slate; they are trying to become productive after Rust has already arrived in their work.

"Funny enough, I've advocated for more niche languages than Rust in the past. Rust has pretty much stopped being as much of a niche language as it was, but it's not Java." -- Fractional CTO

Rust learning resources

Likely as expected, the folks that we talked to reach for a range of resources to learn Rust. Some reach for official documentation, such as The Rust Programming Language Book and find that sufficient to build on what the compiler was already showing them.

"I started with the official Rust documentation because there are a lot of great examples of how features like the borrow checker work." -- Software engineer at an Automotive supplier

Others needed more passes and more formats, sometimes reaching for resources the community maintains, such as Rustlings, The Little Book of Rust Macros, and Learn Rust With Entirely Too Many Linked Lists.

"The first time I went through the chapter in [The Rust Programming Language] on borrow checking, I was like, what is this? I read it again, then I watched a YouTube video of someone explaining the chapter." -- Rust freelance consultant

"Rust book, Rustlings, Zero to Production in Rust, Jon Gjengset tutorials. A bunch of books. It's not a one-pass reading. Can't say how many times I've gone through it." -- Software engineer working on video streaming and storage

These resources have brought up an entire generation of Rust programmers. But, to some, there is a perception that these resources have trouble keeping pace with the language.

"We'd like to use [The Rust Programming Language/'the book'], but we've found that it's out of date, unfortunately. We've looked at the GitHub repo and found it's got a lot of unresolved issues and unmerged PRs" -- Principal Software Engineering work on Rust adoption in a regulated industry

Whether or not this is factually true, Rust's growth has nonetheless put more scrutiny on these materials. Companies evaluating adoption and engineers getting reassigned to Rust teams are looking at them with fresh eyes and finding the gaps that affect their own evaluation.

Beginner stumblings and unlearning habits

It's pretty typical for Rust to be the 2nd, 3rd or Nth programming language that someone picks up. They'd end up writing their most familiar language in Rust, whether C++ patterns, Java patterns, or whatever they knew, for months or even years. Eventually they got comfortable enough to start writing idiomatic Rust.

"There's a bit of a drop in productivity compared to C if you're already familiar with it just because you're learning new rules, new syntax." -- Principal Firmware Engineer (mobile robotics)

"In the beginning it was more poking around the code and adding and removing some ampersands and asterisks to try to make sense of mut and not mut and whatever." -- Senior engineer with 20 years of Java experience in cloud and IoT

We also spoke with someone who found that not having much of a programming background seemed to benefit people picking up Rust. Not having worn-in grooves from other languages may play a role here, and it's worth investigating further.

"I had someone who had never programmed much before start working on the internals of [our Rust project]. She was just fine with getting into Rust. It's more of the senior people that struggle as they need to unlearn practices which may work in other languages, but it's not the 'Rust' way." -- Researcher, Automotive OEM R&D Lab

Learning to work with the borrow checker

We heard a lot about learning to work with the borrow checker instead of against it. People get there through different paths, but a few patterns came up repeatedly.

The compiler as teacher

Rust's diagnostics did the teaching on their own, especially around lifetimes.

"If you mess up the lifetimes in a piece of code that you've written by hand, I usually find that Rust's diagnostics are very helpful" -- Researcher working on static analysis of Rust programs

"Whatever's missing, the compiler usually fills in: it tells me 'you need to declare the lifetime of this reference', so I know and can figure it out. That all generally works pretty well." -- Senior Software Engineer

Learning by doing

Others felt like they only really internalized the borrow checker after writing a lot of Rust. It took projects, coding challenges, prototyping and so on until at some point it clicked.

"I actually did not understand the borrow checker until I spent a lot of time writing Rust" -- Founder of a startup built on Rust

"Besides the prototyping work, I also did coding-challenge-type stuff to get familiar with Rust for Advent of Code. [..] It eventually clicked to the point where I wasn't fighting with Rust, it was working for me. I had that experience other people describe: when I managed to get my program to fit with Rust, it worked. I didn't spend time debugging." -- Principal Software Engineer, large SaaS provider

Letting go of "clone guilt"

Some learners arrive with the assumption that good Rust means zero clones, zero copies, lifetimes threaded through everything. They set the bar at optimal before they've learned how to write idiomatic Rust, and it makes the borrow checker feel harder than it needs to be at the outset.

"On one of my first projects, I was like, 'I don't ever want to copy or clone anything,' so I carefully wove through all the lifetimes and got myself into a bit of a bind. Then I saw someone else just cloning the struct I was working with, and it was super cheap. Sometimes you can just clone and it's going to be okay." -- Researcher at a university

The experienced Rust developers we spoke with consistently said the same thing: clone freely while you're learning, then optimize when you understand the problem. Rust's reputation for performance and correctness feeds this. Newcomers assume anything less than optimal is wrong before they've written a first working program, and clone guilt is how that shows up.

We think it could be an interesting area of future study to check into the patterns Rust programmers employ at different levels of experience and under which circumstances. One member of the Rust Vision doc team that's very experienced with Rust noted that there's kind of an "expected shape" they understand as passing the compiler. This knowledge influences how they approach writing code which wouldn't take that shape and they naturally find themselves understanding when to use so-called workarounds, such as passing around indices into arrays or Vecs.

Multi-paradigm, but not the OOP some are used to

The Rust programming language is multi-paradigm, and how that lands depends on what you're coming from. We heard some that came from a functional background were delighted with digging into learning how much Rust inherits from that lineage. Some others noted that they and others on their teams struggled to unlearn the object-oriented style they'd come to use heavily in other languages like C++ and Java.

"Developers coming from C++ tend to think object-oriented. I think that's a difference between C++ and Rust." -- Architect at Automotive OEM

"I had exactly that thing, where I would apply all my years of Java and JS thinking, where I could just create some object, not care about it, return it, have it sloshing around between various functions. Found myself reaching for these patterns and then being told 'no, you cannot do that'." -- Principal Engineer at a SaaS company

Developers coming from functional programming had less to unlearn: strong typing, pattern matching, and an expression-oriented style were already familiar.

"My background has been more functional programming, strong typing. That originated for me as a Lisper: once a Lisper, always a Lisper." -- Principal Software Engineer working on Rust tooling for safety-regulated industries

"The languages I primarily used before Rust were things like OCaml. Way back, I came from C and C++, the classic languages, and then I spent quite a long time doing primarily pure functional stuff. These days I've ended up back in what I like to think of as a pragmatic center ground [with Rust]." -- Fractional CTO

Teaching Rust in academia

We spoke with a university professor that's been teaching Rust generally. In the academic environment, they were able to use proxies for some things such as "traits are like interfaces in Java" because the students had already gone through a set of courses in their first and second years that taught them Java. They introduced concepts slowly throughout the course, choosing to deal with some more complex topics like generics later. The outcome generally was that students had no problem picking up Rust in this setting.

"I couldn't see any big difference on the embedded side. We also teach an embedded class, and we did an experiment. Half of the students' feedback was worse on the Rust class, mostly because they needed to build the project themselves. The C students just got one from [an LLM], absolutely no problem." -- University Professor, on teaching Rust

The C cohort leaned on LLMs for the project in ways the Rust cohort couldn't. We don't yet have a clear answer for why.

What did come through clearly was the Rust cohort's experience with the community. Some students needed to figure out which drivers to use for the embedded project and how to use them. Their professor encouraged them to open issues and ask questions directly on GitHub, and the maintainers responded. Students who had never contributed to open source before were getting answers from the people who wrote the code.

Learning using LLMs

Some experienced folks shared that they saw LLMs as a tool that can help someone come up to speed quickly, either as a research tool or for generating example Rust code to understand concepts.

"I'm optimistic that there's a way to work [LLMs] in that will cut down that learning curve. One of the big things these tools bring is reducing the learning curve in general; these are very good tools to help you navigate a space that you don't know yet." -- Maintainer of large open source Rust crate

"I try [LLMs] out once a month, usually for generating an example or something like this. Just like with Stack Overflow: when you read an example, you should read it carefully and try to understand it. Not copy and paste it, but type it in your own words in code and then check it, because that's where the teeny tiny little mistakes are." -- Founder of startup built on Rust

For some learners, an LLM is just another way to find answers, no different than a search engine.

"So for the most part, picking up Rust - how do I learn? I'll [use web search for] things, I'll ask [an LLM], I'll just poke around and read the code." -- Senior Software Engineer working in a regulated space

One founder went further and claimed that LLMs change who can become a Rust developer. One consulting company founder described hiring high school graduates with no systems programming background and training them as Rust developers, with LLMs filling in the learning gaps that would previously have required years of experience.

"At the beginning, I was worried, but now that we have [LLMs] supporting development, the difficulty of the language doesn't matter. I'm seeing a huge opportunity behind strong runtime languages like Rust. [..] In [Developing Country] we hire 20-25 high school graduates, train them to be Rust programmers, then they enhance our workforce worldwide." -- Founder of a consulting company

We heard this from one organization. This is a claim that the combination of Rust's compiler and LLM tooling can dramatically shorten the path from beginner to working developer. Whether it generalizes depends on questions we can't answer from a single interview: how long these developers stay, what kind of code they can maintain independently, and whether this training/learning model works outside this company's particular structure. If it holds up, the pool of people who can become Rust developers is much larger than the usual hiring profile suggests.

Organizational considerations for Rust learners

We spoke with a number of folks on teams that are using Rust in larger organizations. Teams wanted to know that everyone would end up at roughly the same level of competence, which led a good number to invest in training courses to get there. Some leaders found that staff was able to ramp well enough by reading The Rust Programming Language, going through Rustlings, and then picking up lower risk and priority tickets to work on. Having a sense of community was also important within companies; it helps people know they are not alone when they are asked to work on Rust after, say, a reorganization happens.

"[..] the idea with the class as opposed to 'just read the Rust book on your own' was that this gives everyone kind of the same baseline going in." -- Principal Firmware Engineer (mobile robotics)

"So typically we're going to have people work through Rustlings, work through The Rust Programming Language. We have them then start to pick up lower risk tickets to work on." -- Principal Engineer at a large SaaS provider

"We've got an internal Slack channel for Rust learning where people can drop questions and others will come in and answer them. That helps build up understanding and community." -- Software Engineer at a large corporation

Some organizations found that while the person they'd hire would need to learn Rust, it was still preferable to the alternative of hiring someone for a critical piece of software written in another language.

"They needed to grow and maintain this C++ codebase. They had a C++ wizard, and they tried for about two years to find someone with the same level of expertise. They ended up hiring people that didn't know Rust and ramping them up, creating FFI bindings from the C++ side so they could work in Rust. And you can feel it: the borrow checker is teaching these people the right way to handle their systems." -- Principal Engineer at an Automotive OEM

The community and helping each other aspect seems to grow bonds as organizations mature.

"Our team is [all about] mentorship. I've mentored people coming up to speed on Rust, and people help each other hugely." -- Principal Software Engineer at a large SaaS company

Silent attrition

We identified some cases where people have approached Rust and bounced off of it, for one reason or another. In the below case, someone with a background in a language with fewer guardrails found themselves frustrated enough with Rust to walk away.

"All of that means that that embedded ecosystem is very frustrating to somebody who comes from C and is like, why can't I just get a pointer to this peripheral and then write into the registers. What are you doing to me? [..] My friend never got over that. He looked at it and said, I'm not going to deal with this and walked away." -– A second University Professor

There may be language features that for a particular domain are not seen as comfortable or usable yet, such as async Rust usage in a safety domain. We'd like to map which language features feel off-limits in which domains; async in safety-critical work probably isn't the only case.

"We're not fully sure how async [Rust] will work out in the long run in our domain. [..] People don't feel comfortable yet since C++14 doesn't provide such concepts. [..] It's the chicken-and-egg problem again: we probably need to gain some experience to see whether we can actually benefit from these new concepts in the automotive and safety domains." -- Team Lead at Automotive Supplier (ASIL D target)

We heard in at least one case, that while the language was challenging and there was a near bounce, the tooling helped keep them coming back and trying.

"Well, I think my early impressions of Rust - one is I find C++ so intimidating, and I think a big part of why I was able to succeed at [..] learning Rust is the tooling. I mean, all this makes sense [..] but it's like, for me, getting started with Rust, the language was challenging, but the tooling was incredibly easy." -- Founder of another startup built on Rust

While it might be considered more of a community concern, if there are interactions online and in spaces that point to learners having so-called "skill issues" this feeds into the narrative that Rust must be hard to learn. We may be unintentionally turning away Rust Project contributors and maintainers due to the vibes being put out when new learners show up in certain spaces.

"People are very helpful, but generally the attitude is: if your program is very complicated, it's mostly a skill issue. There's not that much empathy when people get stuck learning, and a lot of people are just pushed away by it. There's probably a huge number of people who silently stop wanting to write Rust, because at some point it gets complicated and the feedback they get is 'you just need to be a better programmer, obviously'." -- Software Engineer at a SaaS Provider

Feedback on near-bounces from survey

We found a few interesting perspectives collected in the Rust Vision doc survey which we administered with examples of bouncing and coming back:

"I started before 1.0, got stuck very soon when trying to translate patterns from C++ to Rust (due to borrow checking). I tried again after 1.0 and it stuck. [..]" -- Survey Respondent A

Survey Respondent A went on to share in a more detailed response about a perceived weakness in Rust learning materials related to lifetimes and the borrow checker are explained. There was an observation that it's fairly easy to run into more complex situations with lifetimes and the borrow checker. They felt that the current state of this sort of material and tutorials is fairly superficial and can leave learners stuck when they run into those more complex situations.

One respondent that bounced once and came back shared challenges around usage of async. In concert with Rust's memory-safety and the borrow checker, they found some of the nitty-gritty details of async were difficult to learn. While we're aware of the Rust Project's continuous efforts to improve Rust's async story, this is another data point of a user that faced challenges.

Another survey respondent shared how they had multiple times bounced in trying to learn Rust. They returned after a year or so and found Rustlings to be highly motivating. We note that having multiple pathways for folks to learn Rust opens up more possibilities for those that nearly bounced, just like this person.

Need more focused work on silent attritrion

The thing that stood out most to us was the lack of real, first-hand knowledge of having bounced when learning Rust. While this is an obvious effect of soliciting answers to our survey and opportunities to interview through Rust channels and our networks, this cohort is good future candidate where interviews could start.

Conclusions

Across these conversations, the experience of learning Rust depended heavily on context. Why someone was learning and what support they had mattered as much as the borrow checker. The same kinds of examples kept coming up: a training course that got a team to a shared baseline, a maintainer answering a student's first GitHub issue, and a colleague whose code showed that cloning was okay.

That context is largely something the community has a hand in. With that in mind, here is what we take away from what we heard, and what we still don't know.

What seems worth trying

Learning materials aimed at unlearning. Syntax barely came up when people described their struggles. People struggled with unlearning habits from previous languages, whether OOP structuring from C++ and Java or the instinct to grab a raw pointer to a peripheral. Most of our learning materials teach Rust from first principles, and that works. What we didn't come across is much written for, say, the engineer with ten years of Java who lands on a Rust team after a reorg: material that names the patterns they'll reach for that won't transfer, and shows what to do instead. The professor we spoke with did a version of this in the classroom, leaning on "traits are like interfaces in Java" and saving generics for later in the course, and the students did fine. Something similar could work outside the classroom too.

Put the "clone freely while you're learning" advice somewhere official. Every experienced developer we spoke with gave the same advice, but learners seem to mostly pick it up by accident, like the researcher who happened to see someone else cloning the struct they had been carefully threading lifetimes through. Saying it early in official materials would take some of the steepness out of the curve. The broader version belongs there too: idiomatic Rust doesn't have to mean optimal Rust, especially on a first project.

Diagnostics are already a primary learning resource: several people told us the compiler taught them lifetimes before any documentation did. Diagnostics reach learners right at the moment they're stuck. When writing new ones, it seems worth keeping the confused newcomer in mind alongside the expert, because for a lot of people this is where the learning happens.

Is "the book" actually out of date? Whether or not The Rust Programming Language or other materials are actually behind, a team evaluating Rust looked at its repository, saw unresolved issues and unmerged PRs, and moved on. As more companies evaluate adoption, more people will look at these materials with the same fresh eyes. Visible issue triage and some communication about what's current and what's planned would address the perception, separately from whatever content work may or may not be needed.

How stuck learners get treated is shaping who stays. We heard about students getting answers on GitHub from the maintainers who wrote the code, and we heard about learners being told their struggles were a skill issue. The first group came away with a lasting good impression of Rust. Some of the second group walked away entirely, and because they leave quietly, it's easy to underestimate how many of them there are. The welcoming side of the community came up unprompted as a reason people stayed, so we know it makes a difference when we get this right.

Every organization we spoke with described essentially the same ramp-up for bringing a team to Rust. Teams that brought groups of developers to Rust described roughly the same approach: get everyone to a shared baseline with a training course or with The Rust Programming Language and Rustlings, start people on lower-risk tickets, and give them somewhere internal to ask questions. Several organizations also found that hiring developers without Rust experience and ramping them up worked out better than continuing to search for rare expertise in another language. None of this is complicated, and teams weighing adoption don't need to invent a training program from scratch.

What we still don't know

The biggest gap is the people we didn't reach. Nearly everyone we spoke with stuck with Rust long enough to be reachable through Rust channels, so the stories of bouncing off came to us second-hand: a friend who walked away from embedded Rust, colleagues who quietly stopped after the responses they got. As we wrote in our first post, finding people who decided against Rust takes targeted outreach. If the proposed User Research team comes together, talking with learners who bounced would make a good early project, and learning is probably the area where that research would teach us the most.

We also don't know what to make of LLMs as a learning tool yet. They came up as a search engine, as an example generator, and in one organization's case as something that makes training high school graduates into working Rust developers possible. We saw a classroom where the C cohort leaned on LLMs in ways the Rust cohort couldn't, and we don't have an explanation for it. All of this comes from a handful of conversations, so we treat it as a set of leads to follow up on. Given how quickly the tools are changing, it seems better to study this deliberately than to wait and see what folklore develops.

The folks we spoke with showed that people do get there: with enough passes through the materials and enough code written, it eventually clicks. The opportunities above are mostly about making it work for the people who didn't pick Rust on purpose, and for the ones who would have stuck around if their early experience had gone a little differently.

CVE-2026-65696 | sct Overseerr up to 1.35.0 Push Subscription API userId authorization

Thu, 23 Jul 2026 20:19:01 +0200

A vulnerability described as critical has been identified in sct Overseerr up to 1.35.0. This affects an unknown part of the component Push Subscription API. The manipulation of the argument userId results in authorization bypass. This vulnerability only affects products that are no longer supported by the maintainer. This vulnerability was named CVE-2026-65696. The attack may be performed from remote. There is no available exploit.

Anonymisierendes Linux Tails 7.10: Neuer Shutdown und Videoplayer

Thu, 23 Jul 2026 15:20:58 +0200

Die Maintainer der anonymisierenden Linux-Distribution Tails setzen zum Shutdown auf Gnome-Standard. Neu ist der Videoplayer Celluloid.

Anonymisierendes Linux Tails 7.10: Neuer Shutdown und Videoplayer

Thu, 23 Jul 2026 15:14:58 +0200

Die Maintainer der anonymisierenden Linux-Distribution Tails setzen zum Shutdown auf Gnome-Standard. Neu ist der Videoplayer Celluloid.

CVE-2026-16631 | publint up to 0.1.4 package-manager Command src/node/pack.js child_process.exec os command injection (Issue 236 / EUVD-2026-47863)

Thu, 23 Jul 2026 04:46:33 +0200

A vulnerability described as problematic has been identified in publint up to 0.1.4. This impacts the function child_process.exec of the file src/node/pack.js of the component package-manager Command Handler. The manipulation results in os command injection. This vulnerability is known as CVE-2026-16631. Attacking locally is a requirement. Furthermore, an exploit is available. It is advisable to implement a patch to correct this issue. The project maintainer explains: "I think it's very rare for someone to use this package with untrusted input".

Linux Kernel Team Publishes 432 CVEs In Two Days

Wed, 22 Jul 2026 23:06:12 +0200

Ancient Slashdot reader alanw shares a post from the OSS Security mailing list, where sysadmin Jan Schaumann wonders what to do after the Linux kernel cranked out 432 CVEs in a little over 24 hours: "I understand the position that CVEs were always a flawed way to track or prioritize security changes... But this onslaught really shows it's not feasible to attempt to prioritize individual kernel changes. I'm not sure what to do here going forward." The Register reports: The nixCraft team speculated on social media that AI bug reports are a likely reason for all those kernel CVEs, which wouldn't be without precedent - Linus Torvalds himself said in May that the Linux kernel security mailing list had become "almost entirely unmanageable" due to AI-assisted bug hunting. Nonetheless, Torvalds has described AI as a useful tool for Linux development while still noting it can be a drag for maintainers, both from a workload standpoint and the fact "it keeps finding embarrassing bugs." [...] Unfortunately for Linux sysadmins, the position in which they find themselves in this current mess isn't one that's readily solved. CVEs might be a messy way to track and prioritize security updates, especially when hundreds of them are published over a short period, but without something better, it falls to IT and security teams to determine which vulnerabilities affect their systems and which kernel updates they need to deploy. Senior kernel maintainer Greg Kroah-Hartman replied to Jan's post, pushing back on the idea that the kernel's CVE volume is uniquely unmanageable. The kernel isn't special, he argues -- companies everywhere are finally realizing they need to re-evaluate how they update all of their systems and devices, something that's traditionally been "woefully ignored." On the "just always update" approach, Greg says that's precisely what the kernel community endorses: "This is what the kernel developer community recommends and supports. If you want support from us, do this." Can't manage it yourself? Pay a company for support, or "just use Debian or Yocto as their security practices are amazing." He points to Android as proof the approach scales, calling it "the largest deployment of software in the world" -- billions of devices kept updated "with one very-overworked developer guiding it all." As for reviewing every CVE individually, he notes this can be largely automated by intersecting the files a CVE touches with the files you actually build, which typically trims the relevant set "down to about 10% of the overall total" -- the approach enterprise distros already take for their customers. Panic-mode selective patching gets a blunt "Good luck with that!" -- regulations like the EU's Cyber Resilience Act are set to legislate that habit away ("rightfully so," in his view), and "your insurance company might wish to have a talk with you as well." Greg also warns the flood isn't over: "The number of llm-found issues is only on the rise right now, it's going to be a very long 18 months at the least to dig ourselves out of this mess, and people had BETTER be updating their systems all along the way if they expect to be secure in any way." As for the 432-CVE burst itself, he explains it was simply him catching up on a weeks-old, publicly visible review queue over the weekend -- delayed by "a perfect storm of 6 weeks straight of conferences and vacations" -- so it shouldn't have come as a surprise to anyone watching the public git repo.

Read more of this story at Slashdot.

CVE-2022-3902 | GitLab up to 15.4.5/15.5.4/15.6.0 Project Maintainer log file (Issue 381895 / EUVD-2022-43238)

Wed, 22 Jul 2026 13:03:59 +0200

A vulnerability was found in GitLab up to 15.4.5/15.5.4/15.6.0 and classified as problematic. This affects an unknown function of the component Project Maintainer Handler. Executing a manipulation can lead to sensitive information in log files. This vulnerability is registered as CVE-2022-3902. It is possible to launch the attack remotely. No exploit is available. It is suggested to upgrade the affected component.

Open-source maintainers still work underfunded as sponsorship crosses $100 million

Tue, 21 Jul 2026 11:10:35 +0200

The post Open-source maintainers still work underfunded as sponsorship crosses $100 million appeared first on IT Security News.

Open-source maintainers still work underfunded as sponsorship crosses $100 million

Tue, 21 Jul 2026 10:54:43 +0200

A maintainer patches a library late at night that ships inside thousands of products, and no invoice follows. Sebastián Ramírez and Caleb Porzio spent years in that position. Ramírez, known as tiangolo, builds tools that other Python projects depend on. Porzio built Livewire and Alpine.js, tools thousands of web developers reach for. That gap carries a cost. Critical projects lose their maintainers to salaried jobs elsewhere, security fixes slow down, and the software supply chain … More →

The post Open-source maintainers still work underfunded as sponsorship crosses $100 million appeared first on Help Net Security.

„HollowByte“: Denial-of-Service-Lücke in OpenSSL

Mon, 20 Jul 2026 13:39:18 +0200

Die OpenSSL-Maintainer haben stillschweigend eine Denial-of-Service-Lücke geschlossen. Okta nennt sie „HollowByte“.

„HollowByte“: Denial-of-Service-Lücke in OpenSSL

Mon, 20 Jul 2026 13:33:08 +0200

Die OpenSSL-Maintainer haben stillschweigend eine Denial-of-Service-Lücke geschlossen. Okta nennt sie „HollowByte“.

Rust Will Help Linux Succeed and Makes Coding Fun, Says Greg Kroah-Hartman

Mon, 20 Jul 2026 07:54:12 +0200

Read more of this story at Slashdot.

CVE-2026-16129 | princezuda SafestClaw up to 4.2.4 Built-in Web Interface shell.py ShellAction._validate_command incomplete blacklist (Issue 59 / EUVD-2026-45390)

Sun, 19 Jul 2026 12:09:46 +0200

A vulnerability labeled as problematic has been found in princezuda SafestClaw up to 4.2.4. This vulnerability affects the function ShellAction._validate_command of the file src/safestclaw/actions/shell.py of the component Built-in Web Interface. Such manipulation leads to incomplete blacklist. This vulnerability is traded as CVE-2026-16129. An attack has to be approached locally. Furthermore, there is an exploit available. The presence of this vulnerability remains uncertain at this time. The project maintainer explains: "On paper you're correct, this is a vulnerability. In practice, nothing your AI generated shows how it makes users vulnerable. It's open source. Someone can mod the shell allow list or remove that system. Present an actual poc that shows a threat to users."

Java was a three-day hotfix away from dying horribly on stage

Sat, 18 Jul 2026 15:47:53 +0200

Tim Lindholm, Java's original JVM maintainer, shares with El Reg some of the grungy build details the doc glosses over

NextBSD returns to dollop Apple source on FreeBSD

Sat, 18 Jul 2026 09:48:25 +0200

New maintainer revives the project with Darwin components, Gershwin, and Claude Code

CVE-2022-4990 | ASUS AI Suite 3 up to 3.2.x IOCTL improper validation of specified quantity in input

Fri, 17 Jul 2026 17:13:01 +0200

A vulnerability was found in ASUS AI Suite 3 up to 3.2.x. It has been declared as critical. Affected by this vulnerability is an unknown functionality of the component IOCTL Handler. Such manipulation leads to improper validation of specified quantity in input. This vulnerability only affects products that are no longer supported by the maintainer. This vulnerability is documented as CVE-2022-4990. The attack needs to be performed locally. There is not any exploit available. It is recommended to upgrade the affected component.

CVE-2022-4989 | ASUS AI Suite 3 up to 3.2.x IOCTL improper validation of specified quantity in input

Fri, 17 Jul 2026 17:12:58 +0200

A vulnerability was found in ASUS AI Suite 3 up to 3.2.x and classified as critical. This impacts an unknown function of the component IOCTL Handler. The manipulation results in improper validation of specified quantity in input. This vulnerability only affects products that are no longer supported by the maintainer. This vulnerability is cataloged as CVE-2022-4989. The attack must be initiated from a local position. There is no exploit available. It is suggested to upgrade the affected component.

AI OK in Linux development, says Torvalds

Fri, 17 Jul 2026 16:19:36 +0200

Linus Torvalds has a complicated relationship with AI, seeing both its good and bad points. But his latest remarks on the usefulness of AI may have raised a few eyebrows in open-source circles.

Just a few weeks after the Linux founder complained that a “continued flood” of AI-generated vulnerability reports had made the Linux kernel security mailing list “almost entirely unmanageable”, he has come to see the advantages of the technology.

“Linux is not one of those anti-AI projects,” Torvalds wrote in an email response to Linux Kernel senior engineer Roman Gushchin, archived at Kernel.org.

“It can also be a somewhat painful tool, both for maintainer workloads and just from a ‘it keeps finding embarrassing bugs’ standpoint,” he said of the use of AI in security scanning. “The solution is to make sure those LLM tools help maintainers instead of just causing them pain.”

Developers should be free to choose whether they use AI, he said. “We’re not forcing anybody to use it, but I will very loudly ignore people who try to argue against other people from using it.”

Torvalds’ measured support for AI does not come completely out of the blue: Around the same time that he was complaining about AI distorting security maintenance, he also spoke about its usefulness, claiming that it could improve programmer productivity by a factor of 10.

AI OK in Linux development, says Torvalds

Fri, 17 Jul 2026 16:18:17 +0200

Linus Torvalds has a complicated relationship with AI, seeing both its good and bad points. But his latest remarks on the usefulness of AI may have raised a few eyebrows in open-source circles.

“Linux is not one of those anti-AI projects,” Torvalds wrote in an email response to Linux Kernel senior engineer Roman Gushchin, archived at Kernel.org.

This article first appeared on InfoWorld.

Linux Creator Linus Torvalds Rejects Anti-AI Push and Defends LLM Tools

Fri, 17 Jul 2026 08:38:58 +0200

Linux creator and top-level kernel maintainer Linus Torvalds has made it clear that the Linux kernel project will not adopt an anti-AI stance. He believes that large language models and related tools should be assessed based on their technical value…

The post Linux Creator Linus Torvalds Rejects Anti-AI Push and Defends LLM Tools appeared first on IT Security News.

Linux Creator Linus Torvalds Rejects Anti-AI Push and Defends LLM Tools

Fri, 17 Jul 2026 07:53:51 +0200

The post Linux Creator Linus Torvalds Rejects Anti-AI Push and Defends LLM Tools appeared first on GBHackers Security | #1 Globally Trusted Cyber Security News Platform.

CVE-2026-63086 | huggingface text-generation-inference up to 3.3.7 router/src/validation.rs fetch_image image_url server-side request forgery (EUVD-2026-44953)

Thu, 16 Jul 2026 22:06:13 +0200

A vulnerability, which was classified as problematic, was found in huggingface text-generation-inference up to 3.3.7. Affected is the function fetch_image of the file router/src/validation.rs of the component OpenAI-Compatible Multimodal Chat Completions Endpoint. Such manipulation of the argument image_url leads to server-side request forgery. This vulnerability only affects products that are no longer supported by the maintainer. This vulnerability is listed as CVE-2026-63086. The attack may be performed from remote. There is no available exploit.

New Agent Data Injection Attack Can Make AI Agents Misclick or Run Attacker Commands

Thu, 16 Jul 2026 14:53:16 +0200

Ask an AI agent to summarize the reviews on a product page, and a single planted review can make it click “Buy Now” instead. Ask a coding assistant to apply a maintainer’s fix from a GitHub thread, and a fake…

The post New Agent Data Injection Attack Can Make AI Agents Misclick or Run Attacker Commands appeared first on IT Security News.

New Agent Data Injection Attack Can Make AI Agents Misclick or Run Attacker Commands

Thu, 16 Jul 2026 14:39:54 +0200

Ask an AI agent to summarize the reviews on a product page, and a single planted review can make it click "Buy Now" instead. Ask a coding assistant to apply a maintainer's fix from a GitHub thread, and a fake comment can make it run a stranger's command on your computer. Neither trick hijacks the agent's task. Each one just corrupts the facts it trusts and lets it carry on with the job you

CVE-2026-29515 | MiCode FileExplorer SwiFTP Server incorrect implementation of authentication algorithm

Thu, 16 Jul 2026 13:21:35 +0200

A vulnerability, which was classified as critical, was found in MiCode FileExplorer. This impacts an unknown function of the component SwiFTP Server. Such manipulation leads to incorrect implementation of authentication algorithm. This vulnerability only affects products that are no longer supported by the maintainer. This vulnerability is uniquely identified as CVE-2026-29515. The attack can be launched remotely. No exploit exists.

Node.js security starts before CI

Thu, 16 Jul 2026 11:04:19 +0200

In many teams, dependency security still happens after the most important trust decision has already been made. A package is added, the lockfile changes, the feature moves forward, and only later does the pipeline ask whether the application should have trusted that code in the first place.

That workflow made sense when dependency security was mostly viewed as a compliance check. Run a scanner. Produce a report. Fail the build if the risk crosses a threshold. Let someone decide what to do next.

But the modern Node.js ecosystem has changed. The risk no longer begins in CI. It begins earlier, at the moment a developer decides to trust a package.

That is why the next phase of Node.js security cannot be limited to better pipeline enforcement. It has to move closer to the developer workflow, before dependencies become part of the application, before a pull request becomes someone else’s problem, and before a build log becomes the first moment anyone realizes that something important has changed.

Every install is a trust decision

The npm ecosystem is built on trust at an enormous scale. Every install is a trust decision. Every transitive dependency extends that decision to maintainers, packages, scripts, release pipelines, and infrastructure the application team may never inspect directly. This model gave JavaScript its incredible velocity. It also created one of its deepest security weaknesses.

Recent npm supply chain incidents show why this matters. In March 2026, malicious Axios versions were published to npm through a compromised maintainer account. Microsoft later described how those packages attempted to retrieve a second-stage payload during installation. In May 2026, TanStack published a postmortem explaining that 84 malicious versions across 42 npm packages were published through a legitimate release pipeline after an attacker abused GitHub Actions behavior and runner trust boundaries. Security researchers also reported broader Mini Shai-Hulud activity across the npm ecosystem in May, including hundreds of malicious package versions published in a short period.

Not every one of these incidents is a traditional CVE. Some are malicious package compromises. Some involve CI/CD credential theft. Some involve maintainer or pipeline compromise. But they all point to the same larger issue: dependency risk is now part of everyday software engineering, not something that can be pushed entirely to a downstream security process.

The problem is not the scanner. It is the handoff.

Ubiquitous dependency risk changes what developers need from security tooling.

The problem is not that teams lack scanners. Many organizations already run security checks in CI. The problem is that the output of those checks often arrives too late and speaks the wrong language for the person expected to act on it.

A pull request fails. A long vulnerability report appears. The report may be technically accurate. It may contain the right advisory IDs, affected versions, dependency paths, severity labels, and references. But the developer still has to comb through the output and reconstruct the actual engineering decision from the evidence provided.

That reconstruction is rarely simple. The developer has to understand which package introduced the issue, whether the vulnerable dependency is direct or transitive, whether the fix is actually within the application team’s control, and whether the recommended version is safe to adopt. They also have to determine whether the dependency is used in production or only during development, whether the update might break the application, and whether the fix belongs in the current pull request or requires separate engineering work.

That uncertainty is where security work often slows. The scanner has detected risk, but the developer has not been given a clear path from detection to decision.

Security needs to move closer to engineering judgment

This is not a criticism of scanning. Scanning is necessary. CI enforcement is necessary. Centralized security platforms are necessary. But they are not sufficient, because they often operate after the trust decision has already been made.

The real architectural question is this: where should dependency security live in the software development life cycle?

If it lives only in CI, it becomes an interruption. If it lives only in dashboards, it becomes someone else’s queue. If it lives only in periodic audits, it becomes a backlog. But if it lives at the moment a dependency is introduced, upgraded, or reviewed, it becomes part of engineering judgment.

That shift matters because modern JavaScript development is becoming faster than human review can comfortably handle. Developers no longer add dependencies only by reading documentation and choosing libraries manually. AI coding assistants can suggest packages, generate install commands, modify package files, and rewrite code around third-party APIs. Agentic development workflows can make dependency changes as part of broader automated refactors.

AI makes the trust boundary harder to see

That acceleration is useful. It also changes the risk model.

When a human developer adds one package, the team can review the decision. When a coding agent modifies several dependencies as part of a larger task, the trust boundary becomes harder to see. The package file changes, the lockfile changes, the application still runs, and the pull request may look like a normal feature update. But the real security question may be hidden inside the dependency graph.

This is where Node.js teams need a different mental model.

Dependency adoption should not be treated as a small implementation detail. It should be treated as an architectural decision with security consequences. A new package is not just code reuse. It is a new trust relationship.

That does not mean developers should stop using packages. The npm ecosystem exists because reuse works. Most teams cannot and should not build everything themselves. But convenience should not erase visibility. If a dependency becomes part of the application, the team should understand what was added, what changed in the lockfile, what risk comes with it, and what action is available if something is wrong.

Developers need confidence, not just reports

The same applies to remediation. Developers do not want a wall of vulnerability text. They want confidence. They want to know what action reduces risk, what version should be targeted, whether the change is safe, and whether the fix is actually under their control. A vulnerability report that leaves the developer uncertain may satisfy a process requirement, but it does not necessarily improve the speed or quality of remediation.

That is the gap many teams feel today. Security tools are often very good at saying, “There is a problem.” They are less consistent at helping the developer answer, “What should I do next?”

This is the broader problem I have been exploring through CVE Lite CLI, now an OWASP project. The point is not that one command-line tool solves Node.js security. It does not. The larger idea is that dependency security has to move closer to the developer’s moment of decision. A useful developer-side security workflow should not merely report that risk exists. It should help the engineer understand whether the issue is in their control, what change is available, and whether the fix actually reduces risk.

The future is decision support, not just detection

That distinction is important. The future of Node.js security is not just more detection. It is better decision support.

Security teams still need policy. Enterprises still need dashboards. CI still needs gates. But developers need something more immediate: a way to reason about dependency risk while the code is still fresh in their mind. That is where the ecosystem has to evolve.

We already accept that testing belongs close to development. We accept that linting belongs close to development. We accept that formatting, type checking, and build validation belong close to development. Dependency security should follow the same path. It should not be treated as a mysterious report that appears at the end of the process. It should become part of the normal rhythm of engineering work.

Before adding a package, developers should understand what trust relationship is being introduced. Before accepting an AI-generated dependency change, they should inspect what entered the graph. Before merging a pull request, teams should understand whether a vulnerability is direct, transitive, fixable, or blocked by another package. And before treating a CI failure as noise, organizations should ask whether the workflow is giving developers enough information to act confidently.

Node.js security will be won, or lost, before CI runs

The Node.js ecosystem will not become safer by slowing down all development. That is unrealistic. It will become safer when security work is placed where developers can actually use it.

The next generation of Node.js security will be won or lost before CI runs.

It will be won when dependency decisions are still small enough to understand, fresh enough to review, and close enough to the developer for action to feel natural.

That is the shift teams need to make now. Not from insecure to secure in one step, but from late detection to earlier judgment. From vulnerability reports to engineering decisions. From trusting packages by habit to understanding trust as part of software design.

CVE-2026-26214 | Xiaomi Galaxy FDS Android SDK up to 3.0.8 GalaxyFDSClientImpl.createHttpClient certificate host validation

Thu, 16 Jul 2026 10:40:24 +0200

A vulnerability was found in Xiaomi Galaxy FDS Android SDK up to 3.0.8. It has been classified as critical. This vulnerability affects the function GalaxyFDSClientImpl.createHttpClient. Performing a manipulation results in certificate with host mismatch. This vulnerability only affects products that are no longer supported by the maintainer. This vulnerability is reported as CVE-2026-26214. The attack is possible to be carried out remotely. No exploit exists.

CVE-2026-25869 | MiniGal Nano up to 0.3.5 index.php dir path traversal

Thu, 16 Jul 2026 09:38:29 +0200

A vulnerability identified as critical has been detected in MiniGal Nano up to 0.3.5. This vulnerability affects unknown code of the file index.php. The manipulation of the argument dir leads to path traversal. This vulnerability only affects products that are no longer supported by the maintainer. This vulnerability is uniquely identified as CVE-2026-25869. The attack is possible to be carried out remotely. No exploit exists.

CVE-2026-25868 | MiniGal Nano up to 0.3.5 index.php currentdir cross site scripting

Thu, 16 Jul 2026 09:38:23 +0200

A vulnerability was found in MiniGal Nano up to 0.3.5. It has been rated as problematic. This impacts an unknown function of the file index.php. This manipulation of the argument currentdir causes cross site scripting. This vulnerability only affects products that are no longer supported by the maintainer. This vulnerability is handled as CVE-2026-25868. The attack can be initiated remotely. There is not any exploit available.

CVE-2025-71164 | Typesetter CMS up to 5.1 Editing include/tool/Editing.php images cross site scripting (ID 706 / EUVD-2026-2437)

Thu, 16 Jul 2026 07:09:48 +0200

A vulnerability was found in Typesetter CMS up to 5.1. It has been declared as problematic. Affected by this issue is some unknown functionality of the file include/tool/Editing.php of the component Editing Component. Such manipulation of the argument images leads to cross site scripting. This vulnerability only affects products that are no longer supported by the maintainer. This vulnerability is traded as CVE-2025-71164. The attack may be launched remotely. There is no exploit available.

CVE-2025-71166 | Typesetter CMS up to 5.1 Administrative Interface Status.php path cross site scripting (ID 707 / EUVD-2026-2434)

Thu, 16 Jul 2026 07:09:47 +0200

A vulnerability labeled as problematic has been found in Typesetter CMS up to 5.1. Impacted is an unknown function of the file include/admin/Tools/Status.php of the component Administrative Interface. The manipulation of the argument path results in cross site scripting. This vulnerability only affects products that are no longer supported by the maintainer. This vulnerability was named CVE-2025-71166. The attack may be performed from remote. There is no available exploit.

CVE-2025-71165 | Typesetter CMS up to 5.1 Administrative Interface Status.php path cross site scripting (ID 709 / EUVD-2026-2428)

Thu, 16 Jul 2026 07:09:45 +0200

A vulnerability classified as problematic has been found in Typesetter CMS up to 5.1. This affects an unknown function of the file include/admin/Tools/Status.php of the component Administrative Interface. Performing a manipulation of the argument path results in cross site scripting. This vulnerability only affects products that are no longer supported by the maintainer. This vulnerability is identified as CVE-2025-71165. The attack can be initiated remotely. There is not any exploit available.

'Rust makes coding fun again': Why Linux is moving away from C, according to Greg Kroah-Hartman

Wed, 15 Jul 2026 18:34:07 +0200

C won't be disappearing tomorrow, says the stable kernel maintainer, but the future of Linux belongs to Rust.

CVE-2024-36265 | Apache Submarine Server Core 0.8.0 authorization

Tue, 14 Jul 2026 13:55:23 +0200

A vulnerability categorized as critical has been discovered in Apache Submarine Server Core 0.8.0. The affected element is an unknown function. The manipulation results in incorrect authorization. This vulnerability only affects products that are no longer supported by the maintainer. This vulnerability is cataloged as CVE-2024-36265. The attack must originate from the local network. There is no exploit available.

CVE-2026-15483 | TRENDnet TEW-821DAP 1.12B01 ssi /goform/tools_nslookup sub_41EC14 nslookup_target buffer overflow (EUVD-2026-43205)

Sun, 12 Jul 2026 19:08:19 +0200

A vulnerability classified as critical has been found in TRENDnet TEW-821DAP 1.12B01. Impacted is the function sub_41EC14 of the file /goform/tools_nslookup of the component ssi. The manipulation of the argument nslookup_target leads to buffer overflow. This vulnerability only affects products that are no longer supported by the maintainer. This vulnerability is traded as CVE-2026-15483. It is possible to initiate the attack remotely. There is no exploit available. The vendor explains: "We are unable to confirm the existence of the vulnerabilities for (...) TEW-821DAP (v1.0R) as these items have been EOL. "

CVE-2026-15480 | Trendnet TEW-635BRM up to 1.00.03 Web Service /sbin/rc start_httpd device_name stack-based overflow (EUVD-2026-43202)

Sun, 12 Jul 2026 19:08:13 +0200

A vulnerability labeled as critical has been found in Trendnet TEW-635BRM up to 1.00.03. This affects the function start_httpd of the file /sbin/rc of the component Web Service. Such manipulation of the argument device_name leads to stack-based buffer overflow. This vulnerability only affects products that are no longer supported by the maintainer. This vulnerability is documented as CVE-2026-15480. The attack can be executed remotely. Additionally, an exploit exists. The vendor explains: "We are unable to confirm if the vulnerability exists. This item has been EOL since 2011. We will make an official announcement of possible vulnerabilities, and recommend users to switch devices."

CVE-2026-15481 | Trendnet TEW-635BRM up to 1.00.03 IPoA WAN Connection Setup /sbin/rc ipoa_test ipoa_ipaddr command injection (EUVD-2026-43203)

Sun, 12 Jul 2026 19:08:12 +0200

A vulnerability marked as critical has been reported in Trendnet TEW-635BRM up to 1.00.03. This vulnerability affects the function ipoa_test of the file /sbin/rc of the component IPoA WAN Connection Setup. Performing a manipulation of the argument ipoa_ipaddr results in command injection. This vulnerability only affects products that are no longer supported by the maintainer. This vulnerability is reported as CVE-2026-15481. The attack is possible to be carried out remotely. Moreover, an exploit is present. The vendor explains: "We are unable to confirm if the vulnerability exists. This item has been EOL since 2011. We will make an official announcement of possible vulnerabilities, and recommend users to switch devices."

CVE-2026-15496 | SonicCloudOrg sonic-agent up to 2.7.2 Groovy Script GroovyScriptImpl.java evalIsFailed os command injection (EUVD-2026-43218)

Sun, 12 Jul 2026 18:11:12 +0200

A vulnerability described as critical has been identified in SonicCloudOrg sonic-agent up to 2.7.2. The impacted element is the function evalIsFailed of the file sonic-agent/src/main/java/org/cloud/sonic/agent/tests/script/GroovyScriptImpl.java of the component Groovy Script Handler. The manipulation results in os command injection. This vulnerability only affects products that are no longer supported by the maintainer. This vulnerability is reported as CVE-2026-15496. The attack can be launched remotely. Moreover, an exploit is present. The vendor was contacted early about this disclosure but did not respond in any way.

CVE-2026-15484 | TRENDnet TEW-821DAP 1.12B01 ssi /goform/tools_nslookup sub_41EC14 buffer overflow (EUVD-2026-43206)

Sun, 12 Jul 2026 18:11:06 +0200

A vulnerability classified as critical was found in TRENDnet TEW-821DAP 1.12B01. The affected element is the function sub_41EC14 of the file /goform/tools_nslookup of the component ssi. The manipulation results in buffer overflow. This vulnerability only affects products that are no longer supported by the maintainer. This vulnerability is known as CVE-2026-15484. It is possible to launch the attack remotely. No exploit is available. The vendor explains: "We are unable to confirm the existence of the vulnerabilities for (...) TEW-821DAP (v1.0R) as these items have been EOL. "

CVE-2026-15485 | TRENDnet TEW-821DAP 1.11B03 DNS Lookup /goform/tools_nslookup sub_43F2C4 nslookup_target/dns_server os command injection (EUVD-2026-43207)

Sun, 12 Jul 2026 18:11:04 +0200

A vulnerability, which was classified as critical, has been found in TRENDnet TEW-821DAP 1.11B03. The impacted element is the function sub_43F2C4 of the file /goform/tools_nslookup of the component DNS Lookup Handler. This manipulation of the argument nslookup_target/dns_server causes os command injection. This vulnerability only affects products that are no longer supported by the maintainer. This vulnerability is handled as CVE-2026-15485. The attack can be initiated remotely. There is not any exploit available. The vendor explains: "We are unable to confirm the existence of the vulnerabilities for (...) TEW-821DAP (v1.0R) as these items have been EOL. "

CVE-2026-15486 | TRENDnet TEW-821DAP 1.11B03 Firmware Update /goform/tools_ddns sub_42026C hostname/username/password os command injection (EUVD-2026-43208)

Sun, 12 Jul 2026 18:11:03 +0200

A vulnerability, which was classified as critical, was found in TRENDnet TEW-821DAP 1.11B03. This affects the function sub_42026C of the file /goform/tools_ddns of the component Firmware Update Handler. Such manipulation of the argument hostname/username/password leads to os command injection. This vulnerability only affects products that are no longer supported by the maintainer. This vulnerability is uniquely identified as CVE-2026-15486. The attack can be launched remotely. No exploit exists. The vendor explains: "We are unable to confirm the existence of the vulnerabilities for (...) TEW-821DAP (v1.0R) as these items have been EOL. "

CVE-2026-15487 | TRENDnet TEW-821DAP 1.11B03 Firmware Update /goform/system_ntp sub_41FBD0 Hostname os command injection (EUVD-2026-43209)

Sun, 12 Jul 2026 18:11:02 +0200

A vulnerability has been found in TRENDnet TEW-821DAP 1.11B03 and classified as critical. This impacts the function sub_41FBD0 of the file /goform/system_ntp of the component Firmware Update Handler. Performing a manipulation of the argument Hostname results in os command injection. This vulnerability only affects products that are no longer supported by the maintainer. This vulnerability was named CVE-2026-15487. The attack may be initiated remotely. There is no available exploit. The vendor explains: "We are unable to confirm the existence of the vulnerabilities for (...) TEW-821DAP (v1.0R) as these items have been EOL. "

CVE-2026-15495 | SonicCloudOrg sonic-agent up to 2.7.2 Android WebSocket Server AndroidWSServer.java path os command injection (EUVD-2026-43217)

Sun, 12 Jul 2026 17:08:59 +0200

A vulnerability marked as critical has been reported in SonicCloudOrg sonic-agent up to 2.7.2. The affected element is an unknown function of the file AndroidWSServer.java of the component Android WebSocket Server. The manipulation of the argument path leads to os command injection. This vulnerability only affects products that are no longer supported by the maintainer. This vulnerability is documented as CVE-2026-15495. The attack can be initiated remotely. Additionally, an exploit exists. The vendor was contacted early about this disclosure but did not respond in any way.

CVE-2026-15497 | SonicCloudOrg sonic-agent up to 2.7.2 JWT Authentication Filter ExchangeController.java code injection (EUVD-2026-43219)

Sun, 12 Jul 2026 17:08:51 +0200

A vulnerability classified as critical has been found in SonicCloudOrg sonic-agent up to 2.7.2. This affects an unknown function of the file sonic-server-controller/src/main/java/org/cloud/sonic/controller/controller/ExchangeController.java of the component JWT Authentication Filter. This manipulation causes code injection. This vulnerability only affects products that are no longer supported by the maintainer. This vulnerability appears as CVE-2026-15497. The attack may be initiated remotely. In addition, an exploit is available. The vendor was contacted early about this disclosure but did not respond in any way.

CVE-2026-54369 | acl up to 2.3.x link following (Nessus ID 326364)

Sat, 11 Jul 2026 15:53:23 +0200

A vulnerability categorized as critical has been discovered in acl up to 2.3.x. This issue affects the function acl_get_file/acl_set_file/acl_extended_file/acl_delete_def_file. Executing a manipulation can lead to link following. This vulnerability only affects products that are no longer supported by the maintainer. This vulnerability is registered as CVE-2026-54369. The attack needs to be launched locally. No exploit is available. It is advisable to upgrade the affected component.

The open source library holding up your stack might have one maintainer

Fri, 10 Jul 2026 09:35:17 +0200

The post The open source library holding up your stack might have one maintainer appeared first on IT Security News.

The open source library holding up your stack might have one maintainer

Fri, 10 Jul 2026 09:08:09 +0200

Every serious software product runs on code that someone else wrote and released for free. A web service leans on a cryptography library, a data pipeline pulls in a parser, and a mobile app ships a handful of small utilities that one person maintains in spare time. All of it carries the same label. A new paper argues that the single label hides differences large enough to change how each piece behaves once it lands … More →

The post The open source library holding up your stack might have one maintainer appeared first on Help Net Security.

Roundcube Webmail 1.7.2 Fixes Zero-Click XSS, SSRF Bypass, and DoS Flaws

Fri, 10 Jul 2026 07:23:42 +0200

Roundcube has released version 1.7.2, a security-focused update addressing six vulnerabilities, including two CVE-tracked flaws that could allow attackers to execute stored cross-site scripting (XSS) without any user interaction. Maintainer alecpl pushed the release five days ago, urging all production deployments to update immediately after backing up data. The most severe issue, tracked as CVE-2026-54433, […]

The post Roundcube Webmail 1.7.2 Fixes Zero-Click XSS, SSRF Bypass, and DoS Flaws appeared first on Cyber Security News.

Beliebter Dropbox-Client für macOS vor dem Aus

Thu, 09 Jul 2026 10:32:30 +0200

Sam Schott, Maintainer von Maestral, gibt auf. Die App wird künftig nicht mehr entwickelt. Er selbst nutze Dropbox nicht mehr.

This Week In Rust: This Week in Rust 659

Thu, 09 Jul 2026 07:08:34 +0200

Hello and welcome to another issue of This Week in Rust! Rust is a programming language empowering everyone to build reliable and efficient software. This is a weekly summary of its progress and community. Want something mentioned? Tag us at @thisweekinrust.bsky.social on Bluesky or @ThisWeekinRust on mastodon.social, or send us a pull request. Want to get involved? We love contributions.

This Week in Rust is openly developed on GitHub and archives can be viewed at this-week-in-rust.org. If you find any errors in this week's issue, please submit a PR.

Want TWIR in your inbox? Subscribe here.

Updates from Rust Community

Official

Newsletters

The Embedded Rustacean Issue #75

Project/Tooling Updates

Observations/Thoughts

Rust Walkthroughs

Miscellaneous

Clickable euler diagram of all the Rust week talks

Crate of the Week

This week's crate is apis-saltans, a Zigbee implementation including a coordinator API.

Thanks to Richard Neumann for the self-suggestion!

Please submit your suggestions and votes for next week!

Calls for Testing

An important step for RFC implementation is for people to experiment with the implementation and give feedback, especially before stabilization.

If you are a feature implementer and would like your RFC to appear in this list, add a call-for-testing label to your RFC along with a comment providing testing instructions and/or guidance on which aspect(s) of the feature need testing.

No calls for testing were issued this week by Rust, Cargo, Rustup or Rust language RFCs.

Let us know if you would like your feature to be tracked as a part of this list.

Call for Participation; projects and speakers

CFP - Projects

Always wanted to contribute to open-source projects but did not know where to start? Every week we highlight some tasks from the Rust community for you to pick and get started!

Some of these tasks may also have mentors available, visit the task page for more information.

* Protocol - Extend bit-exactness tests to f64 reconstruction targets
* Dofigen - No image tag replacement flag for the generate command

If you are a Rust project owner and are looking for contributors, please submit tasks here or through a PR to TWiR or by reaching out on Bluesky or Mastodon!

CFP - Events

Are you a new or experienced speaker looking for a place to share something cool? This section highlights events that are being planned and are accepting submissions to join their event as a speaker.

If you are an event organizer hoping to expand the reach of your event, please submit a link to the website through a PR to TWiR or by reaching out on Bluesky or Mastodon!

Updates from the Rust Project

598 pull requests were merged in the last week

Compiler

Library

Cargo

Rustdoc

Clippy

Rust-Analyzer

Rust Compiler Performance Triage

This week was dominated by wild swings in benchmarks of the new-solver, which is not enabled by default, yet. Apart from that, we got a very few notable changes, only one unexpected speedup from a bugfix in rustdoc.

Triage done by @panstromek. Revision range: 7dc2c162..3659db0d

Summary:

(instructions:u)	mean	range	count
Regressions ❌ (primary)	0.2%	[0.2%, 0.2%]	3
Regressions ❌ (secondary)	162.1%	[0.2%, 1116.3%]	20
Improvements ✅ (primary)	-1.4%	[-8.4%, -0.1%]	7
Improvements ✅ (secondary)	-1.1%	[-8.4%, -0.1%]	11
All ❌✅ (primary)	-0.9%	[-8.4%, 0.2%]	10

1 Regression, 1 Improvement, 4 Mixed; 3 of them in rollups 17 artifact comparisons made in total

Full report here

Approved RFCs

Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week:

No RFCs were approved this week.

Final Comment Period

Every week, the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now.

Tracking Issues & PRs

Rust

Compiler Team (MCPs only)

Language Reference

Empty repr(Rust) enums are ZSTs

No Items entered Final Comment Period this week for Cargo, Language Team, Leadership Council, Rust RFCs or Unsafe Code Guidelines.

New and Updated RFCs

Upcoming Events

Rusty Events between 2026-07-08 - 2026-08-05 🦀

If you are running a Rust event please add it to the calendar to get it mentioned here. Please remember to add a link to the event too. Email the Rust Community Team for access.

Jobs

Please see the latest Who's Hiring thread on r/rust

Quote of the Week

if a ptr is dereferenced in a forest and nobody hears it, is it sound?

– Kornel on rust-users

Thanks to Cerber-Ursi for the suggestion!

Please submit quotes and vote for next week!

This Week in Rust is edited by:

Email list hosting is sponsored by The Rust Foundation

Discuss on r/rust

Nick Desaulniers returns as a maintainer for LLVM/Clang support in the kernel: "I'm coming back. I will return. I will possess your body, and I'll make LKML burn."

Thu, 09 Jul 2026 03:54:33 +0200

submitted by /u/anh0516
[link] [comments]

Siemens SINEC OS

Tue, 07 Jul 2026 18:55:49 +0200

View CSAF

Summary

SINEC OS before V4.0 contains multiple vulnerabilities. Siemens has released a new version for RUGGEDCOM RST2428P and recommends to update to the latest version.

The following versions of Siemens SINEC OS are affected:

RUGGEDCOM RST2428P (6GK6242-6PA00) vers:intdot/<4.0

CVSS	Vendor	Equipment	Vulnerabilities
v3 9.8	Siemens	Siemens SINEC OS	Improper Restriction of Operations within the Bounds of a Memory Buffer, Improper Resource Shutdown or Release, Integer Overflow or Wraparound, Stack-based Buffer Overflow, Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'), Uncontrolled Recursion, Out-of-bounds Read, Covert Timing Channel, Improper Input Validation, Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution'), Improper Update of Reference Count, Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'), Multiple Releases of Same Resource or Handle, Permissive Regular Expression, Expired Pointer Dereference, Incorrect Bitwise Shift of Integer, Out-of-bounds Write, User Interface (UI) Misrepresentation of Critical Information, Improper Access Control, Insertion of Sensitive Information Into Sent Data, Inefficient Algorithmic Complexity, Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'), Authentication Bypass by Primary Weakness, NULL Pointer Dereference, Active Debug Code, Loop with Unreachable Exit Condition ('Infinite Loop'), Missing Synchronization, External Control of File Name or Path, Privilege Dropping / Lowering Errors, Use of Web Browser Cache Containing Sensitive Information

Background

Critical Infrastructure Sectors: Critical Manufacturing, Transportation Systems, Energy, Healthcare and Public Health, Financial Services, Government Services and Facilities
Countries/Areas Deployed: Worldwide
Company Headquarters Location: Germany

Metrics

CVSS Version	Base Score	Base Severity	Vector String
3.1	5.7	MEDIUM	CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:N/A:N

Acknowledgments

Siemens ProductCERT reported these vulnerabilities to CISA.

General Recommendations

As a general security measure, Siemens strongly recommends to protect network access to devices with appropriate mechanisms. In order to operate the devices in a protected IT environment, Siemens recommends to configure the environment according to Siemens' operational guidelines for Industrial Security (Download: https://www.siemens.com/cert/operational-guidelines-industrial-security), and to follow the recommendations in the product manuals. Additional information on Industrial Security by Siemens can be found at: https://www.siemens.com/industrialsecurity

Additional Resources

For further inquiries on security vulnerabilities in Siemens products and solutions, please contact the Siemens ProductCERT: https://www.siemens.com/cert/advisories

Terms of Use

The use of Siemens Security Advisories is subject to the terms and conditions listed on: https://www.siemens.com/productcert/terms-of-use.

Legal Notice and Terms of Use

This product is provided subject to this Notification (https://www.cisa.gov/notification) and this Privacy & Use policy (https://www.cisa.gov/privacy-policy).

Recommended Practices

CISA recommends users take defensive measures to minimize the exploitation risk of this vulnerability.

Minimize network exposure for all control system devices and/or systems, and ensure they are not accessible from the internet.

Locate control system networks and remote devices behind firewalls and isolate them from business networks.

When remote access is required, use more secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most recent version available. Also recognize VPN is only as secure as its connected devices.

CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.

CISA also provides a section for control systems security recommended practices on the ICS webpage on cisa.gov. Several CISA products detailing cyber defense best practices are available for reading and download, including Improving Industrial Control Systems Cybersecurity with Defense-in-Depth Strategies.

CISA encourages organizations to implement recommended cybersecurity strategies for proactive defense of ICS assets. Additional mitigation guidance and recommended practices are publicly available on the ICS webpage at cisa.gov in the technical information paper, ICS-TIP-12-146-01B--Targeted Cyber Intrusion Detection and Mitigation Strategies.

Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.

Advisory Conversion Disclaimer

This ICSA is a verbatim republication of Siemens ProductCERT SSA-253495 from a direct conversion of the vendor's Common Security Advisory Framework (CSAF) advisory. This is republished to CISA's website as a means of increasing visibility and is provided "as-is" for informational purposes only. CISA is not responsible for the editorial or technical accuracy of republished advisories and provides no warranties of any kind regarding any information contained within this advisory. Further, CISA does not endorse any commercial product or service. Please contact Siemens ProductCERT directly for any questions regarding this advisory.

Revision History

Initial Release Date: 2026-06-02

Date	Revision	Summary
2026-06-02	1	Publication Date
2026-07-07	2	Initial CISA Republication of Siemens ProductCERT SSA-253495 advisory

Legal Notice and Terms of Use

PolinRider: Nordkoreanische Supply-Chain-Attacken missbrauchen npm, Packagist, Go-Module und Chrome-Extensions

Sun, 05 Jul 2026 23:52:39 +0200

LONDON (IT BOLTWISE) – PolinRider zeigt, wie stark sich Supply-Chain-Angriffe weiterentwickelt haben: Angreifer platzieren dutzende schädliche Pakete und Browser-Erweiterungen in beliebten Ökosystemen wie npm, Packagist, Go-Module und dem Chrome Web Store. Betroffen sind nicht nur Entwickler-Workstations, sondern auch CI/CD-Pipelines, die Abhängigkeiten automatisch abrufen und ausführen. Das Vorgehen nutzt kompromittierte Maintainer-Accounts, stark obfuscated JavaScript-Loader und mehrstufige […]

... den vollständigen Artikel »PolinRider: Nordkoreanische Supply-Chain-Attacken missbrauchen npm, Packagist, Go-Module und Chrome-Extensions« lesen

Dieser Beitrag PolinRider: Nordkoreanische Supply-Chain-Attacken missbrauchen npm, Packagist, Go-Module und Chrome-Extensions erschien als erstes auf IT BOLTWISE x Artificial Intelligence.

CVE-2026-14650 | connorskees grass up to 0.13.4 UTF-8 Character raw_to_parse_error denial of service (Issue 116 / EUVD-2026-41694)

Sun, 05 Jul 2026 02:39:01 +0200

A vulnerability labeled as problematic has been found in connorskees grass up to 0.13.4. The affected element is the function grass_compiler::raw_to_parse_error of the component UTF-8 Character Handler. Executing a manipulation can lead to denial of service. This vulnerability is tracked as CVE-2026-14650. The attack is restricted to local execution. Moreover, an exploit is present. In Issue #117 with similar structure the project maintainer explains: "DoS vulnerabilities are generally fine in Sass compilers -- they are trivially possible with recursive functions, infinite loops, nested mixins, etc. The description here is wrong. Compile time is not expected to be linear relative to the input, and the @extend algorithm is definitionally exponential."

CVE-2026-14651 | connorskees grass up to 0.13.4 visitor denial of service (Issue 117 / EUVD-2026-41695)

Sun, 05 Jul 2026 02:38:55 +0200

A vulnerability marked as problematic has been reported in connorskees grass up to 0.13.4. The impacted element is the function grass_compiler::selector::extend/grass_compiler::evaluate::visitor. The manipulation leads to denial of service. This vulnerability is listed as CVE-2026-14651. The attack must be carried out locally. In addition, an exploit is available. The project maintainer explains: "DoS vulnerabilities are generally fine in Sass compilers -- they are trivially possible with recursive functions, infinite loops, nested mixins, etc. The description here is wrong. Compile time is not expected to be linear relative to the input, and the @extend algorithm is definitionally exponential."

PolinRider: Nordkoreanische Hacker streuen 108 Malware-Pakete über npm & Co.

Sat, 04 Jul 2026 22:07:56 +0200

LONDON (IT BOLTWISE) – Nordkoreanisch verlinkte Angreifer aus der „Contagious Interview“-Kampagne veröffentlichen 108 bösartige Pakete und Browser-Extensions über mehrere Ökosysteme wie npm, Packagist, Go und Chrome. Laut einer aktuellen Analyse bleiben die Aktivitäten aktiv, weil Maintainer-Accounts kompromittiert und Versionen in legitimen Repositories infiziert werden. Für Teams, die Build-Pipelines und Abhängigkeiten pflegen, verschiebt sich damit die […]

... den vollständigen Artikel »PolinRider: Nordkoreanische Hacker streuen 108 Malware-Pakete über npm & Co.« lesen

Dieser Beitrag PolinRider: Nordkoreanische Hacker streuen 108 Malware-Pakete über npm & Co. erschien als erstes auf IT BOLTWISE x Artificial Intelligence.

North Korean Hackers Publish 108 Malicious Packages and Extensions in PolinRider Campaign

Sat, 04 Jul 2026 13:53:39 +0200

The North Korean threat actors linked to the Contagious Interview campaign have been observed publishing 108 unique packages and web browser extensions spanning npm, Packagist, Go, and Google Chrome as part of an ongoing activity referred to as PolinRider. "The campaign remains active, and new malicious packages are likely to continue appearing as threat actors compromise maintainer accounts,

Hackers Compromise GitHub Maintainer Accounts to Publish PolinRider-Infected Package Versions

Fri, 03 Jul 2026 07:08:18 +0200

A widescale escalation in the PolinRider supply‑chain campaign: threat actors have compromised GitHub maintainer accounts to publish infected package versions across multiple ecosystems. The investigation identified 162 malicious release artifacts across 108 unique packages and extensions in npm, Packagist, Go modules, and a Chrome extension, linking this activity to the broader North Korean Contagious Interview […]

The post Hackers Compromise GitHub Maintainer Accounts to Publish PolinRider-Infected Package Versions appeared first on GBHackers Security | #1 Globally Trusted Cyber Security News Platform.

Hackers Compromise GitHub Maintainer Accounts to Publish PolinRider-Infected Package Versions

Fri, 03 Jul 2026 07:08:13 +0200

The post Hackers Compromise GitHub Maintainer Accounts to Publish PolinRider-Infected Package Versions appeared first on IT Security News.

CVE-2026-58460 | ajith-ab react-native-receive-sharing-intent ContentProvider path traversal (EUVD-2026-41437)

Fri, 03 Jul 2026 02:07:58 +0200

A vulnerability was found in ajith-ab react-native-receive-sharing-intent. It has been declared as critical. This affects an unknown part of the component ContentProvider Handler. Such manipulation leads to path traversal. This vulnerability only affects products that are no longer supported by the maintainer. This vulnerability is traded as CVE-2026-58460. Access to the local network is required for this attack to succeed. There is no exploit available. It is advisable to implement a patch to correct this issue.

Godot Game Engine No Longer Accepts AI Code

Thu, 02 Jul 2026 21:07:53 +0200

The Godot Foundation will stop accepting AI-authored code, agent-submitted pull requests, and AI-generated text in contributor communications after maintainers were overwhelmed by low-effort submissions. "It is time for us to recognize that these problems aren't going away and therefore we need to take steps to reduce the burden on maintainers while ensuring we still have a pipeline to mentor new contributors to become future maintainers," the Godot Foundation said in a blog post. Contributors may still use AI for limited "menial things" if they disclose it, but humans must understand, own, and be able to fix the code they submit. PC Gamer reports: The Foundation says the pileup of Godot pull requests pending review isn't all bad: It's a sign that interest in using and contribution to Godot is increasing. But the influx of contributions authored or submitted by AI is sapping the projects' maintainers of their willingness to confront the "already tedious" work of reviewing pull requests. "If your feedback on PRs is just being absorbed by a machine and not going towards mentoring a potential future maintainer, it becomes much harder to justify spending your free time on PR review," the Foundation said. As the problem becomes increasingly unsustainable, the Godot Foundation says it's in the process of updating its contribution policies, focusing on "adding barriers to low-effort slop" contributions, encouraging maintainers to review code, developing new contributors into future maintainers, and crucially, requiring that all contributions come from humans who are accountable for their code -- and fixing it if it fails. "AI cannot take responsibility, and we can't trust heavy users of AI to understand their code enough to fix it," the Foundation said. The Foundation says we can expect Godot's contributing policy to soon include explicit rejections of AI-authored code, noting that contributors should only use AI assistance for "menial things" and must disclose its use. Additionally, the Foundation will reject any AI-generated text in human-to-human communications, saying it's "a basic principle of respect" -- though it says machine translations "are still acceptable" if the original text was human-authored. "Things change every day with respect to the current suite of AI tools available," the Foundation said. "We will continue taking a conservative approach in our policies towards them, but we will re-evaluate as things evolve."

Read more of this story at Slashdot.

CVE-2026-11998 | Google AngularJS 1.2.0-rc.3 Regular Expression angularjs.org incomplete filtering of special elements (Nessus ID 323783)

Thu, 02 Jul 2026 14:10:40 +0200

A vulnerability classified as critical was found in Google AngularJS 1.2.0-rc.3. Affected is an unknown function of the file angularjs.org of the component Regular Expression Handler. The manipulation results in incomplete filtering of special elements. This vulnerability only affects products that are no longer supported by the maintainer. This vulnerability was named CVE-2026-11998. The attack may be performed from remote. There is no available exploit.

CVE-2026-50043 | Seiko Solutions SkyBridge MB-A100/SkyBridge MB-A110 os command injection (EUVD-2026-40929)

Wed, 01 Jul 2026 13:26:19 +0200

A vulnerability has been found in Seiko Solutions SkyBridge MB-A100 and SkyBridge MB-A110 and classified as critical. This vulnerability affects unknown code. The manipulation leads to os command injection. This vulnerability only affects products that are no longer supported by the maintainer. This vulnerability is referenced as CVE-2026-50043. Remote exploitation of the attack is possible. No exploit is available.

Software Bill of Material umsetzen: Die besten SBOM-Tools

Wed, 01 Jul 2026 06:08:11 +0200

Nur wenn Sie wissen, was drinsteckt, können Sie sich sicher sein, dass alles mit rechten Dingen zugeht. Das gilt für Fast Food wie für Software.

Foto: Geka – shutterstock.com

Um Software abzusichern, muss man wissen, was in ihrem Code steckt. Aus diesem Grund ist eine Software Bill of Material, SBOM oder Software-Stückliste heute unerlässlich. Der SolarWinds-Angriff sowie die Log4j-Schwachstelle haben verdeutlicht, wie wichtig es ist, die Sicherheit von Softwarelieferketten in den Fokus zu nehmen – insbesondere, wenn es um Open Source Software geht. Einer Umfrage (PDF) des Open-Source-Unternehmens Tidelift zufolge enthalten heute 92 Prozent aller Anwendungen Open-Source-Komponenten. Eine durchschnittliche, moderne Applikation besteht demnach sogar zu 70 Prozent aus quelloffener Software.

Die Antwort auf die potenziellen Risiken sind – wenn es nach der Linux Foundation, der Open Source Security Foundation und OpenChain geht – SBOMs: Formale und maschinenlesbare Metadaten, die ein Softwarepaket und seinen Inhalt eindeutig identifizieren. Die Software-Stücklisten können auch andere Informationen enthalten, etwa Copyright- oder Lizenzdaten. Dabei ist eine Software Bill of Material so konzipiert, dass sie organisationsübergreifend ausgetauscht werden kann. Besonders hilfreich ist eine SBOM, um die Transparenz über die von den Teilnehmern einer Softwarelieferkette gelieferten Komponenten zu gewährleisten.

SBOM – Best Practices

Eine SBOM sollte beinhalten:

die Open-Source-Bibliotheken der Anwendung;
Plugins, Erweiterungen und andere Zusatzmodule;
von In-House-Entwicklern selbst geschriebenen Quellcode;
Informationen über die Versionen dieser Komponenten, ihren Lizenzierungs- und Patch-Status;
automatische kryptografische Signatur und Überprüfung von Komponenten;
automatische Scans, um SBOMs als Teil der CI/CD-Pipeline zu erstellen.

Dabei sollte eine Software Bill of Material ein einheitliches Format verwenden. Zu den gängigen SBOM-Formaten gehören:

Software Package Data Exchange (SPDX),
Software Identification (SWID) Tagging und
OWASP CycloneDX.

Bislang hat sich keiner der drei Standards von den anderen abgesetzt und einen De-facto-Industriestandard geschaffen. Um SBOMs praktikabel zu machen, sollte die SBOM-Erstellung nicht nur automatisiert, sondern in die CI/CD-Pipeline integriert werden. Oder wie die National Telecommunications and Information Administration (NTIA) es ausdrückt (PDF): “Das ultimative Ziel ist es, SBOMs in Maschinengeschwindigkeit zu generieren.”

Software Bill of Materials – Use Cases

Auch bei SBOMs gibt es drei verschiedene Anwendungsfälle. Im Allgemeinen sind das:

Softwarehersteller verwenden SBOMs, um Erstellung und Wartung der von ihnen gelieferten Software zu unterstützen.
Softwareeinkäufer nutzen SBOMs, um sich vor dem Kauf abzusichern, Rabatte auszuhandeln und Implementierungsstrategien aufzusetzen.
Softwarebetreiber nutzen SBOMs für das Vulnerability- und Asset-Management, um Lizenzen und Compliance zu managen und Abhängigkeiten und Risiken in Sachen Software und Komponenten schnell zu identifizieren.

Empfehlenswerte SBOM-Tools

Bei drei verschiedenen SBOM-Formaten und einer Vielzahl von Metadaten, die innerhalb einer Software Bill of Material verfolgt werden können, ist es nicht verwunderlich, dass es kein SBOM-Tool gibt, das sämtliche Bedürfnisse erfüllt. Gartner empfiehlt, Tools zu verwenden, die folgende Funktionen mitbringen:

SBOMs während des Build-Prozesses erstellen;
Quellcode und Binärdateien (wie Container-Images) analysieren;
SBOMs bearbeiten;
SBOMs in lesbaren Formaten anzeigen, vergleichen, importieren und validieren;
SBOM-Inhalte von einem Format oder Dateityp in andere übersetzen, beziehungsweise die Informationen zusammenführen;
Einbindung anderer Tools über APIs und Bibliotheken;

Keines der folgenden acht Tools erfüllt (bislang) all diese Empfehlungen. Wir empfehlen Ihnen, die Tools auszuprobieren und anschließend zu ermitteln, welches für Ihre Zwecke am besten geeignet ist. Diese acht SBOM-Tools verdienen Ihre Aufmerksamkeit:

Anchore

Das Unternehmen ist bereits seit sechs Jahren im SBOM-Business tätig. Die Grundlage des Unternehmens bilden zwei Open-Source-Projekte:

Syft ist ein Tool mit Kommandozeilen-Interface und eine Bibliothek, um SBOMs aus Container-Images und Dateisystemen zu erzeugen.
Grype ist ein einfach zu integrierendes Tool, um Container-Images und Dateisysteme auf Schwachstellen zu scannen.

Zusammen können diese beiden Werkzeuge Software-Stücklisten in jeder Phase des Entwicklungsprozesses erzeugen, von Quellcode-Repositories und CI/CD-Pipelines bis hin zu Container-Registries und Laufzeiten. Diese SBOMs werden in einem zentralen Repository aufbewahrt, um vollständige Transparenz und kontinuierliches Monitoring zu gewährleisten – auch nach der Bereitstellung. Die Tools von Anchore unterstützen CycloneDX, SPDX und das proprietäre SBOM-Format von Syft. Das Anbieterunternehmen bündelt seine SBOM-Funktionalität in der Plattform Anchore Enterprise 4.0 Software SCM (Supply Chain Management).

FOSSA

Die Flaggschiff-Programme von FOSSA sind ein Open Source License Compliance Manager und ein Open Source Vulnerability Scanner. Der Ansatz von FOSSA sieht vor, dass Sie das SBOM-Tool in Ihr bevorzugtes Versionskontrollsystem wie GitHub, BitBucket oder GitLab integrieren. Sie können auch die CLI von FOSSA verwenden und das Tool lokal ausführen oder es in Ihre CI/CD-Pipeline integrieren.

In jedem Fall identifiziert FOSSA im Rahmen eines Projektscans automatisch sowohl direkte als auch indirekte Abhängigkeiten in der Codebasis.

GitLab (ehemals Rezilion)

Beim DevSecOps-Anbieter ist SBOM Teil seiner ganzheitlichen Software-Sicherheits- und Schwachstellen-Systeme. Dynamic SBOM verwendet eine dynamische Laufzeitanalyse, um die Angriffsfläche Ihrer Software zu monitoren. Es sucht also ständig nach bekannten Schwachstellen in den Komponenten. Neben der Bereitstellung eines Live-Inventars aller Softwarekomponenten in Ihren CI/CD-, Staging- und Produktionsumgebungen wird Ihre SBOM ständig aktualisiert. Sie können Ihre Software Bill of Material im CycloneDX-Format und als Excel-Tabelle exportieren.

Nach der Übernahme durch GitLab wurden die SBOM-Funktionalitäten von Rezilion im Jahr 2022 in die DevSecOps-Plattform integriert.

Mend

Früher unter dem Namen WhiteSource bekannt, bietet Mend eine Vielzahl von SCA-Tools (Software Composition Analysis) an. Eine SBOM-Funktionalität ist in das SCA-Toolset integriert. Die Lösung von Mend ist weniger ein Entwicklerprogramm oder ein CI/CD-Tool – sondern vielmehr ein Open-Source-Lizenz- und Sicherheitsmechanismus für Programmierer.

Mit Hilfe von Mend lassen sich sämtliche Softwarekomponenten tracken, direkte und indirekte Abhängigkeiten identifizieren, Schwachstellen aufdecken, Remediationspfade bereitstellen und automatisch SBOM-Einträge aktualisieren.

SPDX SBOM Generator

Dieses eigenständige Open-Source-Tool tut das, was sein Name verspricht: SPDX-SBOMs aus aktuellen Paketmanagern oder Build-Systemen erstellen. Sie können seine CLI verwenden, um SBOM-Daten aus Ihrem Code zu erzeugen. Das Tool erzeugt Berichte über Komponenten, Lizenzen, Copyrights und Sicherheitsreferenzen Ihres Codes. Diese Daten werden in der SPDX v2.2-Spezifikation exportiert.

Start Left Security

Dieses SBOM-Tool wird als Software-as-a-Service (SaaS) angeboten. Auf der Grundlage einer patentierten, anwendungszentrierten Integrationsmethodik kombiniert das ehemals unter dem Namen TauruSeer bekannte Angebot seine Cognition-Engine-Sicherheitsüberprüfung mit SBOM. Das Paket hilft Ihnen, Ihren Code für Ihre Entwickler und Kunden abzusichern und zu tracken.

Tern Project

Dieses quelloffene SBOM-Projekt lässt sich gut mit SPDX SBOM Generator kombinieren. Anstatt mit Paketmanagern oder Build-Systemen zu arbeiten, erzeugt dieses SCA-Tool und die Python-Bibliothek eine SBOM für Container-Images und Docker-Dateien. Darüber hinaus lassen sich auch SBOMs im SPDX-Format erzeugen.

Vigilant Ops

Dieser Cybersicherheitsanbieter aus dem Healthcare-Bereich konzentriert sich mit seiner InSight-Plattform auf Software-Stücklisten. Seine SaaS-Plattform generiert und pflegt zertifizierte SBOMs und sorgt für deren authentifizierten Austausch. Sie bietet Sicherheit durch kontinuierliche Schwachstellenüberwachung. Die SBOM-Zertifizierung verwendet patentierte Algorithmen, um sicherzustellen, dass alle Komponenten validiert und Schwachstellen verlinkt sind.

Die Sicherheitsfunktionen können auch für SBOMs verwendet werden, die von anderen Programmen erstellt wurden. Diese werden sowohl im Ruhezustand als auch während der Übertragung verschlüsselt.

Dieser Artikel ist im Original bei unserer Schwesterpublikation CSOonline.com erschienen.

CVE-2026-2818 | VMware Spring Data Geode/Spring Data Gemfire on Windows Import Snapshot path traversal

Wed, 01 Jul 2026 04:08:48 +0200

A vulnerability was found in VMware Spring Data Geode and Spring Data Gemfire on Windows. It has been classified as critical. This vulnerability affects unknown code of the component Import Snapshot Handler. Performing a manipulation results in relative path traversal. This vulnerability only affects products that are no longer supported by the maintainer. This vulnerability was named CVE-2026-2818. The attack may be initiated remotely. There is no available exploit.

OFFIS DCMTK Toolkit

Tue, 30 Jun 2026 18:24:28 +0200

View CSAF

Summary

Successful exploitation of these vulnerabilities could allow an attacker to write files, access unauthorized information, exhaust memory, or crash affected DCMTK client or server processes.

The following versions of OFFIS DCMTK Toolkit are affected:

DCMTK <=3.7.0 (CVE-2026-50003, CVE-2026-50254, CVE-2026-35505, CVE-2026-52868, CVE-2026-44628)

CVSS	Vendor	Equipment	Vulnerabilities
v3 9.8	OFFIS	OFFIS DCMTK Toolkit	Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'), Missing Release of Memory after Effective Lifetime, Access of Resource Using Incompatible Type ('Type Confusion')

Background

Critical Infrastructure Sectors: Healthcare and Public Health
Countries/Areas Deployed: Worldwide
Company Headquarters Location: Germany

Vulnerabilities

Expand All +

CVE-2026-50003

A malicious or compromised server can make a DCMTK client using bit-preserving C-GET storage mode write files outside the chosen output directory, using both relative (../) paths and absolute paths.

View CVE Details

Affected Products

OFFIS DCMTK Toolkit

Vendor:
OFFIS

Product Version:
OFFIS DCMTK: <=3.7.0

Product Status:
known_affected

Remediations

Mitigation
The maintainer was notified of these vulnerabilities and has provided a fix. The fix is included in the latest commits and can be obtained in the following snapshot:

Vendor fix
https://github.com/DCMTK/dcmtk/releases/tag/latest.
https://github.com/DCMTK/dcmtk/releases/tag/latest

Mitigation
Users are recommended to download the latest GitHub release once it becomes available.

Relevant CWE: CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')

Metrics

CVSS Version	Base Score	Base Severity	Vector String
3.1	9.8	CRITICAL	CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
4.0	9.3	CRITICAL	CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

CVE-2026-50254

An unauthenticated remote attacker can repeatedly send a single crafted connection request to leak memory. Against storescp in its default single-process mode, memory grows quickly and the service is eventually killed, after which it stops accepting connections until an operator restarts it.

View CVE Details

Affected Products

OFFIS DCMTK Toolkit

Vendor:
OFFIS

Product Version:
OFFIS DCMTK: <=3.7.0

Product Status:
known_affected

Remediations

Mitigation
The maintainer was notified of these vulnerabilities and has provided a fix. The fix is included in the latest commits and can be obtained in the following snapshot:

Vendor fix
https://github.com/DCMTK/dcmtk/releases/tag/latest.
https://github.com/DCMTK/dcmtk/releases/tag/latest

Mitigation
Users are recommended to download the latest GitHub release once it becomes available.

Relevant CWE: CWE-401 Missing Release of Memory after Effective Lifetime

Metrics

CVSS Version	Base Score	Base Severity	Vector String
3.1	7.5	HIGH	CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
4.0	8.7	HIGH	CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

CVE-2026-35505

An unauthenticated remote attacker can repeatedly send crafted connection requests to leak memory. In single-process deployments the memory grows until the service is killed and the port stops responding until restart.

View CVE Details

Affected Products

OFFIS DCMTK Toolkit

Vendor:
OFFIS

Product Version:
OFFIS DCMTK: <=3.7.0

Product Status:
known_affected

Remediations

Mitigation
The maintainer was notified of these vulnerabilities and has provided a fix. The fix is included in the latest commits and can be obtained in the following snapshot:

Vendor fix
https://github.com/DCMTK/dcmtk/releases/tag/latest.
https://github.com/DCMTK/dcmtk/releases/tag/latest

Mitigation
Users are recommended to download the latest GitHub release once it becomes available.

Relevant CWE: CWE-401 Missing Release of Memory after Effective Lifetime

Metrics

CVSS Version	Base Score	Base Severity	Vector String
3.1	7.5	HIGH	CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
4.0	8.7	HIGH	CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

CVE-2026-52868

An unauthenticated attacker can read worklist records from a directory outside the intended per-AE worklist storage area. In a multi-area deployment, this can cross departmental or clinic data separation.

View CVE Details

Affected Products

OFFIS DCMTK Toolkit

Vendor:
OFFIS

Product Version:
OFFIS DCMTK: <=3.7.0

Product Status:
known_affected

Remediations

Mitigation
The maintainer was notified of these vulnerabilities and has provided a fix. The fix is included in the latest commits and can be obtained in the following snapshot:

Vendor fix
https://github.com/DCMTK/dcmtk/releases/tag/latest.
https://github.com/DCMTK/dcmtk/releases/tag/latest

Mitigation
Users are recommended to download the latest GitHub release once it becomes available.

Relevant CWE: CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')

Metrics

CVSS Version	Base Score	Base Severity	Vector String
3.1	8.2	HIGH	CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N
4.0	8.8	HIGH	CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N

CVE-2026-44628

An unauthenticated attacker can crash the worklist server with a single crafted query when the server has a valid Called AE Title / storage directory, the expected lockfile, and at least one matching worklist record.

View CVE Details

Affected Products

OFFIS DCMTK Toolkit

Vendor:
OFFIS

Product Version:
OFFIS DCMTK: <=3.7.0

Product Status:
known_affected

Remediations

Mitigation
The maintainer was notified of these vulnerabilities and has provided a fix. The fix is included in the latest commits and can be obtained in the following snapshot:

Vendor fix
https://github.com/DCMTK/dcmtk/releases/tag/latest.
https://github.com/DCMTK/dcmtk/releases/tag/latest

Mitigation
Users are recommended to download the latest GitHub release once it becomes available.

Relevant CWE: CWE-843 Access of Resource Using Incompatible Type ('Type Confusion')

Metrics

CVSS Version	Base Score	Base Severity	Vector String
3.1	7.5	HIGH	CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
4.0	8.7	HIGH	CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

Acknowledgments

Abhinav Agarwal reported these vulnerabilities to CISA

Legal Notice and Terms of Use

This product is provided subject to this Notification (https://www.cisa.gov/notification) and this Privacy & Use policy (https://www.cisa.gov/privacy-policy).

Recommended Practices

CISA recommends users take defensive measures to minimize the risk of exploitation of these vulnerabilities.

Minimize network exposure for all control system devices and/or systems, ensuring they are not accessible from the internet.

Locate control system networks and remote devices behind firewalls and isolating them from business networks.

When remote access is required, use more secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize VPN is only as secure as the connected devices.

CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.

CISA also provides a section for control systems security recommended practices on the ICS webpage on cisa.gov/ics. Several CISA products detailing cyber defense best practices are available for reading and download, including Improving Industrial Control Systems Cybersecurity with Defense-in-Depth Strategies.

CISA encourages organizations to implement recommended cybersecurity strategies for proactive defense of ICS assets.

Additional mitigation guidance and recommended practices are publicly available on the ICS webpage at cisa.gov/ics in the technical information paper, ICS-TIP-12-146-01B--Targeted Cyber Intrusion Detection and Mitigation Strategies.

Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.

CISA also recommends users take the following measures to protect themselves from social engineering attacks:

Do not click web links or open attachments in unsolicited email messages.

Refer to Recognizing and Avoiding Email Scams for more information on avoiding email scams.

Refer to Avoiding Social Engineering and Phishing Attacks for more information on social engineering attacks.

No known public exploitation specifically targeting these vulnerabilities has been reported to CISA at this time.

Revision History

Initial Release Date: 2026-06-30

Date	Revision	Summary
2026-06-30	1	Initial Publication

Legal Notice and Terms of Use

CVE-2026-8402 | SYSGUARD 6001 up to 2.0.1 sql injection (EUVD-2026-40296)

Tue, 30 Jun 2026 16:52:28 +0200

A vulnerability, which was classified as critical, was found in Eksagate Electronic Engineering and Computer Industry Trade SYSGUARD 6001 up to 2.0.1. Affected is an unknown function. Executing a manipulation can lead to sql injection. This vulnerability only affects products that are no longer supported by the maintainer. The identification of this vulnerability is CVE-2026-8402. The attack may be launched remotely. There is no exploit available. You should upgrade the affected component.

The Servo Blog: May in Servo: user scripts, mp4 compat, blackboxing in DevTools, and more!

Tue, 30 Jun 2026 10:07:49 +0200

Servo 0.3.0 contains all of the changes we landed in May, which came out to 391 commits (March: 534). For security fixes, see § Security.

We’ve shipped several new web platform features:

‘font-kerning: none’ (@simonwuelker, #44634)
‘font-variant-east-asian’ (@simonwuelker, #44989)
‘font-variant-ligatures’ (@simonwuelker, #44903)
‘font-variant-numeric’ (@simonwuelker, #44950)
‘font-variant-position’ (@simonwuelker, #45142)
mp4 files without fast start in (@calvaris, #45084)
(@yezhizhen, #45028)
(@yezhizhen, #45111)
layout (@mrobinson, #44791)

Plus a bunch of new DOM APIs:

onslotchange property on ShadowRoot (@jdm, #44688)
screenLeft and screenTop on Window (@TG199, #45128)
new Blob() with {endings: "native"} (@yezhizhen, #44803)
new PerformanceMark() (@shubhamg13, #44702)
parseHTML() on Document (@kkoyung, #44952)
readAsBinaryString() on FileReader (@yezhizhen, #44858, #44921)
performance.measure() with mark values ‘redirectStart’, ‘redirectEnd’, ‘secureConnectionStart’, and ‘responseEnd’ (@shubhamg13, #44673, #44624, #44850, #44739)

We’ve also fixed some build issues on Windows (@mukilan, #45079), FreeBSD (@delan, @mrobinson, @mukilan, #44600), and for anyone building Servo on NixOS or with Nix (@freyacodes, #45051, #45135).

This is another big update, so here’s an outline:

Security
– memory safety fixes
Work in progress
– execCommand(), Sanitizer, IndexedDB, accessibility, workers
Embedding API
– MSRV, cookies, preferences, diagnostics
For users and developers
– --host-file, --userscripts, DevTools Debugger
More on the web platform
– focus, forms, navigation, SubtleCrypto, WebGPU
Performance
– about:memory, threads, layout, DOM, build times
Stability
– crashes, hangs, static analysis

Security

Servo’s JS runtime, SpiderMonkey 140.10.0, had several memory safety bugs that have been fixed in Servo 0.3.0 with the update to SpiderMonkey 140.10.1 (@jschwe, #44755). For more details, see CVE-2026-7322, CVE-2026-7323, and MFSA 2026-36.

Work in progress

We’re continuing to implement document.execCommand() for rich text editing, under --pref dom_exec_command_enabled (@TimvdLippe, #44735, #44973, #44887). This release adds support for the ‘backColor’, ‘foreColor’, ‘createLink’, ‘unlink’, ‘superscript’, ‘subscript’, and ‘removeFormat’ commands (@TimvdLippe, #44644, #44682, #44657, #44710, #44677), plus partial support for the ‘insertParagraph’ command (@TimvdLippe, #44909).

We’re also working on the Sanitizer API, under --pref dom_sanitizer_enabled. With the feature now enabled in servoshell’s experimental mode (@kkoyung, #44701), this release adds support for setComments(), setDataAttributes(), allowProcessingInstruction(), removeProcessingInstruction(), and removeUnsafe() on Sanitizer (@kkoyung, #44734, #44983).

IndexedDB continues to improve, under --pref dom_indexeddb_enabled. This release brings a more conformant abort() on IDBTransaction (@Taym95, #43950).

All of the features above are enabled in servoshell’s experimental mode.

We’ve made more progress towards accessibility support, including the name from contents algorithm (@alice, @delan, @mrobinson, #44439) and several changes towards building the accessibility tree incrementally (@alice, @delan, @mrobinson, #44766, #45035, #45207, #44768, #44785, #44801, #44767, #45029). The latter is critical for performance in real-world web content.

We’re now working on SharedWorker and ServiceWorker, under --pref dom_sharedworker_enabled and --pref dom_serviceworker_enabled respectively. This release adds support for new SharedWorker() (@Taym95, #44761), and parts of the ServiceWorker API (@gterzian, @arihant2math, #45082, #44787).

Embedding API

Servo now requires Rust 1.88.0 or newer, up from the old MSRV of 1.86.0 (@sagudev, #44815). We run compile tests with the MSRV, but most of our testing is now done with Rust 1.95.0 (@simonwuelker, #44632).

Breaking changes to the cookies methods in our SiteDataManager API (@longvatrong111, #44708):

SiteDataManager::clear_cookies now takes an additional callback argument, allowing it to be called async – to continue calling it sync, pass None as the callback
SiteDataManager::clear_session_cookies now takes an additional callback argument, allowing it to be called async – to continue calling it sync, pass None as the callback
SiteDataManager::set_cookie_for_url now takes an additional callback argument, allowing it to be called async – to continue calling it sync, pass None as the callback
SiteDataManager::set_cookie_for_url_async has been removed in favour of set_cookie_for_url – to migrate, replace set_cookie_for_url_async(callback) with set_cookie_for_url(Some(Box::new(callback)))

Breaking changes to our Preferences API (@Narfinger, @mrobinson, #44307):

threadpools_image_cache_workers_max, threadpools_indexeddb_workers_max, and threadpools_webstorage_workers_max have been removed in favour of a combined thread_pool_workers_max
threadpools_fallback_worker_num has been renamed to thread_pool_fallback_workers
threadpools_async_runtime_workers_max has been renamed to thread_pool_async_runtime_workers_max
threadpools_webrender_workers_max has been renamed to thread_pool_webrender_workers_max

We’ve also reworked our DiagnosticsLogging API (@mukilan, #44703):

You can now set options with DiagnosticsLogging::toggle_option, and check if they are enabled with DiagnosticsLogging::is_enabled
Each option is a variant of DiagnosticsLoggingOption, a new type that also has useful methods for exposing these options in embedder UI
(Breaking change) DiagnosticsLogging no longer has pub fields representing each option – to migrate, replace field writes and field reads with toggle_option and is_enabled respectively
(Breaking change) DiagnosticsLogging::extend_from_string no longer accepts a help option – this option only existed to support servoshell’s -Z help / --debug=help option, so the code implementing it has been moved to servoshell

For users and developers

servoshell has two new options:

You can now configure the path to a hosts file with --host-file= (singular), as an alternative to the HOST_FILE (singular) environment variable (@jschwe, #44880).
You can now provide a directory of user scripts to run in every document with --userscripts= (@jdm, #44754).

When using the Debugger tab in the Firefox DevTools:

You can now “blackbox” a script by clicking Ignore source (@freyacodes, #44359). This prevents breakpoints from being hit inside that script, and it should also allow you to step through execution in the debugger without pausing inside that script.
The Scopes panel is more accurate now (@atbrakhi, @eerii, #44765).

For developers of Servo itself, please note that per project policy, you must not use the output of large language models or other generative AI tools in your contributions. To help us enforce that, we now have CI checks that reject AI agents as coauthors (@SimonSapin, @delan, #44723).

We’ve also fixed build issues with --features vello (@Gae24, @yezhizhen, #44875, #45036).

More on the web platform

We’ve improved the default appearance of

, , , , ,
, , , , and (@avis137, #44837, #44920).

CryptoKey is now serializable, allowing it to be used in structuredClone() and postMessage() (@kkoyung, #45163).

We’ve improved JS error messages in several parts of the DOM (@n0blenote, @jdm, @TG199, @PuercoPop, #44704, #45186, #44656).

We’ve improved the conformance of form submission (@yezhizhen, #44943, #44953, #44954, #44957), tab navigation (@mrobinson, #44684), javascript: url navigation (@jdm, @TimvdLippe, #43490), ‘Refresh’ headers and (@jschwe, @mrobinson, #45113, #45116), ‘line-break: anywhere’ (@mrobinson, @SimonSapin, #44609), assign() on Location (@TG199, @jdm, #44298), crypto.subtle.deriveBits() (@kkoyung, #44706), getComputedStyle() (@Loirooriol, #44856), performance.measure() (@shubhamg13, #44675), readAsDataURL() on FileReader (@yezhizhen, #44897, #44924), stream() on Blob (@Taym95, #45133), and ML-KEM in SubtleCrypto (@kkoyung, #45153).

We’ve also landed improvements to GPUSupportedLimits (@sagudev, #45114), GPUTexture (@sagudev, #45154), createBindGroup() on GPUDevice (@sagudev, #45140), and other WebGPU features (@sagudev, #45097).

We’ve fixed bugs related to with ‘Content-Security-Policy’ (@TimvdLippe, @jdm, #44974), ‘:active’ (@SharanRP, @mrobinson, #43953), ‘:hover’ (@SharanRP, @mrobinson, #43979), ‘align-items’ (@yezhizhen, #44396), ‘border-image-outset’ (@lumiscosity, #45039), ‘padding’ with ‘overflow: scroll’ (@stevennovaryo, #44263), ‘pointerup’ events (@mrobinson, #44666), ‘slotchange’ events (@jdm, #44688), dynamic import() (@Gae24, #44741), and clip() on CanvasRenderingContext2D (@yezhizhen, #44831).

Performance

We’ve built a tool that will help us improve ‘about:memory’ by finding untracked allocations (@jdm, @TimvdLippe, @webbeef, #44674, #44980).

Servo now requires fewer OS threads per CPU, after we combined the thread pools for the image cache, web storage, and IndexedDB (@Narfinger, @mrobinson, #44307).

We’ve landed a bunch of layout optimisations:

The fragment tree is now immutable for the most part, with small pockets of interior mutability where mutability is needed. This means that most fragment tree accesses no longer have to incur the runtime cost of borrowing an AtomicRefCell (@mrobinson, @Loirooriol, #44849).

Two steps in the layout process, calculating containing blocks and building the stacking context tree, require traversing the fragment tree. This can be expensive, but we’ve now combined them into a single fragment tree traversal in most cases (@SimonSapin, @mrobinson, #44911, #45210).

Another step in the layout process, calculating scrollable overflow, used to require traversing the entire fragment tree. We’ve effectively eliminated that traversal, by making the calculation both lazy and incremental (@mrobinson, @Loirooriol, #44854).

We’ve improved the caching of fragments, shaping results, and other layout results between reflows (@mrobinson, @Loirooriol, @SimonSapin, #45038, #44769).

We’ve made incremental fragment layout more precise (@Loirooriol, @mrobinson, #44925).

We’ve reduced the memory usage of text shaping (@mrobinson, @SimonSapin, #44609).

DOM attributes are much more efficient in this release:

When scripts write attribute values, we avoid serialising them until the attribute is read back by a script (if ever), speeding up frequent writes to inline styles by up to 25% (@mrobinson, #44931).

When we parse attributes in HTML or read attribute values internally, we avoid constructing Attr nodes until a script actually needs them, reducing memory usage and making garbage collection less likely (@webbeef, @TimvdLippe, @mrobinson, #44209, #45023, #45031, #45060).

We’ve eliminated a traversal of the whole DOM tree whenever an is attached to the tree, which is especially noticeable when parsing documents with many tags (@mrobinson, #45236).

Stylesheet locks now use AtomicRefCell, which is even more efficient than a parking_lot::RwLock (@mrobinson, #44883).

On OpenHarmony, we now have a real refresh driver for reduced idle CPU usage (@jschwe, @yezhizhen, #44927), and we now cache the font list on disk for faster startup (@RichardTjokroutomo, @d-desyatkin, #44158).

We’ve also reduced allocations, GC rooting steps, and other operations in many parts of Servo (@jschwe, @kkoyung, @mrobinson, @SteveSharonSam, @Narfinger, @jdm, @nodelpit, @simonwuelker, #44961, #44944, #44972, #45231, #45078, #44662, #44679, #44967, #44963, #44933, #44935, #44905).

To improve Servo’s build times, we’re moving more code out of our massive script crate (@Narfinger, @jdm, #44598, #44636, #44823), and reduced the size of our dependency tree (@jschwe, #44818).

Stability

Several crashes and hangs have been fixed:

in ‘content’ (@mrobinson, @Loirooriol, @SimonSapin, #45227, #44762)

in MediaStream (@jdm, #44781)

in item() on attributes on Element (@webbeef, #44721)

in appendRule() on CSSKeyframesRule (@mrobinson, #45173)

in initEvent() on FocusEvent (@mrobinson, #44870)

in stop() on Window (@TimvdLippe, #44804)

in document.execCommand("delete") (@TimvdLippe, #44748)

in --debug-mozjs builds (@Gae24, @SharanRP, #44745, #45001)

when evaluating scripts in DevTools while paused (@atbrakhi, #45050)

when previewing some JS values in DevTools (@eerii, @atbrakhi, #45054)

when shaping zero-width spaces in layout (@mrobinson, #45176)

when toggling servoshell’s experimental mode at runtime (@mrobinson, @Loirooriol, #45226)

We’ve continued our long-running effort to use the Rust type system to make certain kinds of dynamic borrow failures impossible (@Gae24, @MavenRain, @Narfinger, @SteveSharonSam, @TimvdLippe, @elomscansio, @jdm, @kkoyung, @yezhizhen, #44712, #44759, #44879, #45014, #45058, #45061, #45076, #45098, #45110, #45149, #45117, #45184, #45201, #44806, #44930, #44942, #44946, #45233, #45181, #44659, #44660, #44664, #44668, #44992, #45000, #45081, #45009, #45225, #45087, #45244, #45245, #45247, #44663, #44665, #44993, #45040, #45053, #44647, #44671, #44681, #44717, #44733, #44686, #44653).

New contributors

A special thanks to the following people for landing their first patch in Servo:

AbdAlRahman Gad (@AbdAlRahmanGad, #45213)

Onyeka Obi (@MavenRain, #44806)

Steve Sharon Sam (@SteveSharonSam, #45030)

avis137 (@avis137, #44837)

Xabier Rodríguez (@calvaris, #45084)

June (@kimjune01, #44816)

Matt Van Horn (@mvanhorn, #44740)

nicole (@n0blenote, #44704)

panxt8 (@panxt8, #44991)

Interested in helping build a web browser? Take a look at our curated list of issues that are good for new contributors!

Donations

Thanks again for your generous support! We are now receiving 7659 USD/month (+4.2% from April) in recurring donations. This helps us cover the cost of our speedy CI and benchmarking servers, one of our latest Outreachy interns, and funding maintainer work that helps more people contribute to Servo.

Servo is also on thanks.dev, and already 35 GitHub users (+2 from April) that depend on Servo are sponsoring us there. If you use Servo libraries like url, html5ever, selectors, or cssparser, signing up for thanks.dev could be a good way for you (or your employer) to give back to the community.

We now have sponsorship tiers that allow you or your organisation to donate to the Servo project with public acknowlegement of your support. If you’re interested in this kind of sponsorship, please contact us at join@servo.org.

7659 USD/month

10000

Use of donations is decided transparently via the Technical Steering Committee’s public funding request process, and active proposals are tracked in servo/project#187. For more details, head to our Sponsorship page.

Git 2.55.0 released

Mon, 29 Jun 2026 22:24:01 +0200

Git maintainer Junio Hamano has announced Git 2.55.0, which has non-merge commits from 100 people; 33 of those are first-time contributors to the project. LWN recently covered some of the noteworthy changes in 2.55, including new features for the experimental "git history" command, addition of the Git fsmonitor daemon for Linux systems, and more.

CVE-2024-21490 | angular 1.3.0 ng-srcset Directive redos (SNYK-JS-ANGULAR-6091113 / Nessus ID 242412)

Mon, 29 Jun 2026 18:45:39 +0200
A vulnerability has been found in angular 1.3.0 and classified as problematic. This issue affects some unknown processing of the component ng-srcset Directive Handler. Performing a manipulation results in inefficient regular expression complexity. This vulnerability only affects products that are no longer supported by the maintainer. This vulnerability is cataloged as CVE-2024-21490. It is possible to initiate the attack remotely. There is no exploit available.

[$] Xsnow "protestware" in Debian

Mon, 29 Jun 2026 17:56:23 +0200

The xsnow application, which generates an animated snowfall effect (and other pleasant diversions) for X11 desktops, does not seem like an obvious channel for political statements. Nevertheless, xsnow's maintainer seems to have included a political protest in the program: an Easter egg that is triggered when the program's language is set to Russia ("ru"). One user has complained that this functionality should be removed from the Debian xsnow package, but Debian does not seem to have any rules that forbid such a feature outright.

CVE-2026-13522 | Investintech SlimPDFReader up to 2.0.14 PDF File SlimPDFReader.exe TeighaDo+0x25cde0 out-of-bounds (EUVD-2026-40019)

Mon, 29 Jun 2026 13:54:24 +0200
A vulnerability, which was classified as problematic, has been found in Investintech SlimPDFReader up to 2.0.14. Affected by this issue is the function SlimPDFReader!Investintech::PCV::TeighaDo+0x25cde0 of the file SlimPDFReader.exe of the component PDF File Handler. Performing a manipulation results in out-of-bounds read. This vulnerability only affects products that are no longer supported by the maintainer. This vulnerability is cataloged as CVE-2026-13522. It is possible to initiate the attack remotely. Furthermore, there is an exploit available.

클로드 코드 총괄 “프로토타이퍼·빌더·그로워…AI 시대 조직은 이렇게 바뀐다”

Mon, 29 Jun 2026 12:03:08 +0200

앤트로픽에서 AI 코딩 도구 클로드 코드 개발을 주도하고 관련 팀을 총괄하는 보리스 체르니(Boris Cherny)는 28일 X를 통해 내부 제품 조직을 관찰한 결과를 바탕으로 미래 제품 조직의 다섯 가지 핵심 역할을 제시했다.

첫 번째는 ‘프로토타이퍼(Prototyper)’다. 새로운 아이디어를 끊임없이 발굴하고 빠르게 실험하는 역할이다. 수많은 아이디어를 만들어내지만 실제 제품으로 이어지는 것은 일부에 그친다.

두 번째는 ‘빌더(Builder)’다. 프로토타입이나 아이디어를 빠르게 실제 서비스 수준의 제품과 인프라로 구현하는 역할이다.

세 번째는 ‘스위퍼(Sweeper)’다. 사용자 인터페이스(UI)를 다듬고 코드와 시스템을 단순화하며, 불필요한 기능을 제거하고 성능을 최적화하는 역할을 맡는다.

네 번째는 ‘그로워(Grower)’다. 이미 출시된 제품을 지속적으로 개선하며 제품-시장 적합성(PMF·Product-Market Fit)을 높이는 데 집중한다.

마지막은 ‘메인터이너(Maintainer)’다. 성숙한 시스템의 보안성과 안정성, 성능, 운영 효율성을 유지하고 서비스 확장을 책임지는 역할이다.

체르니는 “많은 사람은 이 가운데 두 가지 역할을 수행하고, 때로는 세 가지 역할까지 아우른다”며 “흥미로운 점은 이러한 역할이 기존 직무와는 크게 관련이 없다는 것”이라고 설명했다.

그는 “앤트로픽에서도 디자이너 가운데는 프로토타이퍼에 가까운 사람이 있는가 하면, 빌더나 스위퍼 역할을 수행하는 사람도 있다”며 “엔지니어, PM, 데이터 사이언티스트 역시 마찬가지”라고 덧붙였다.

또한 체르니는 건강한 제품 조직은 제품의 성장 단계에 따라 필요한 역할의 조합이 달라진다고 설명했다. 초기 제품에는 새로운 아이디어를 만들고 이를 빠르게 구현·정리하는 역할이 중요하다. 제품이 성장하기 시작하면 이를 지속적으로 개선해 PMF를 높이는 역할과 시스템 안정성을 유지하는 역할이 추가된다. PMF를 확보한 성숙한 제품에서는 안정성과 성능 개선, 지속적인 제품 고도화가 핵심이 되며, 새로운 기능 개발을 담당하는 역할은 일부만 필요하다는 설명이다.

체르니는 “어쩌면 미래의 제품 조직은 지금처럼 엔지니어, 디자이너, PM 등 직무별로 구분되기보다 이러한 역할(archetype) 중심으로 구성되는 형태에 더 가까워질지도 모른다”고 밝혔다.

몇몇 IT 업계 리더들도 비슷한 전망을 내놓은 바 있다. 마이크로소프트(MS) CEO 사티아 나델라는 AI 시대에는 업무 방식뿐 아니라 직무의 범위 자체가 재편되고 있다고 진단했다.

나델라는 2025년 공개된 와이콤비네이터(Y Combinator)와의 대담에서 MS가 보유한 링크드인을 사례로 들며 “링크드인은 기존에 별도로 운영되던 제품 디자인, 프런트엔드 엔지니어링, 제품 관리(PM) 기능을 하나의 역할인 ‘풀스택 빌더(Full-stack Builder)’로 통합하기 시작했다”고 설명했다. 그는 “이는 직무의 범위 자체가 달라지고 있다는 의미”라며 “새로운 역할과 직무 범위에 맞춰 제품팀을 어떻게 다시 설계할 것인지가 중요한 과제가 되고 있다”고 말했다.

나델라는 이 같은 변화가 AI 도입의 핵심 병목 중 하나인 ‘변화 관리(change management)’ 문제와 직결된다고 강조했다. 그는 “보험사, 금융사, 헬스케어 기업, 소프트웨어 기업 모두 일하는 방식 전체를 바꾸는 것”이라며 “어떤 직무인지 자체가 달라지는 것”이라고 덧붙였다.

메타(Meta)의 CTO 앤드루 보즈워스도 비슷한 견해를 밝혔다. 그는 2025년 자신의 인스타그램 계정을 통한 라이브 세션에서 AI 도구를 완전히 습득한 개발자와 그렇지 못한 개발자 사이에 “역량의 계층화(tiering of capability)”가 심화될 것이라고 경고했다. 보즈워스는 “AI 도구를 완벽히 익혀 도구로도 대체될 수 없는 엔지니어는 프리미엄을 받게 되고, 그렇지 못한 엔지니어는 데이터 수집이나 레이블링 같은 도구 하위 계층의 작업으로 밀려나게 된다”고 말했다. 그는 “직원 수는 적지만 수십억 명의 사용자를 보유한 기업이 등장하게 될 것”이라며 AI가 소프트웨어 산업을 위축시키는 것이 아니라 오히려 성장시킬 것이라고 강조했다.
jihyun.lee@foundryco.com

Run a 30-year old version of GIMP on modern Linux via Flatpak

Mon, 29 Jun 2026 03:39:42 +0200

Every wondered what GIMP looked like in 1996, before GTK? Well, now you can. Developer balooii has packaged GIMP 0.54 as a Flatpak that runs on modern 64-bit Linux desktops with Wayland. It’s apparently the earliest version of the app with the source code still available to build. It’s not an official GIMP effort, but an enthusiast project hosted on the GNOME GitLab. It’s also something of a work-in-progress package of an ancient work-in-progress beta release, with the maintainer promising more plugins and tutorials in time. Before we get to the install bit, there is a bit of trivia-laden history […]

You're reading Run a 30-year old version of GIMP on modern Linux via Flatpak, a blog post from OMG! Ubuntu. Do not reproduce elsewhere without permission.

CVE-2023-37524 | HCL Traveler for Microsoft Outlook up to 3.0.5 unmaintained third party components (KB0131418 / EUVD-2023-60599)

Sat, 27 Jun 2026 19:09:32 +0200
A vulnerability was found in HCL Traveler for Microsoft Outlook up to 3.0.5. It has been classified as problematic. This vulnerability affects unknown code. Performing a manipulation results in use of unmaintained third party components. This vulnerability only affects products that are no longer supported by the maintainer. This vulnerability is identified as CVE-2023-37524. The attack is only possible with local access. There is not any exploit available.

The "Akrites" vulnerability-mitigation project launches

Fri, 26 Jun 2026 15:23:31 +0200
The Linux Foundation, in a letter co-signed by a large range of organizations and companies, has announced the launch of "Akrites", a project to fast-track vulnerability fixes into projects.

As Akrites works upstream to fix projects at the source, we commit to support downstream efforts to secure critical infrastructure before it can be exploited. When patches are released to the public, adversaries are able to utilize AI to rapidly reverse engineer the underlying vulnerabilities, develop exploits, and launch attacks. The success of our efforts therefore will be measured in patch deployment, not publication. We will partner with critical infrastructure owners and operators, civil society efforts, and governments as they increase coordination to achieve these goals.
Confidentiality is non-negotiable: An undisclosed flaw in a widely deployed package is, in effect, a weapon, and the program is built first to prevent leaks. Fixes flow back into each project's own home, working with the maintainers. The engineering resources and other capabilities provided by Akrites participants contribute to this effort. Additionally, when a critical package has no one maintaining it, Akrites will stand as the maintainer of last resort so a fix can still reach everyone in a timely fashion. We will also align with government efforts so that public and private defenders move together, rather than in a disjointed fashion.

Linux Foundation Launches Akrites To Coordinate AI-Driven Open Source Security

Thu, 25 Jun 2026 23:23:59 +0200
BrianFagioli writes: The Linux Foundation has announced Akrites, a new initiative to coordinate vulnerability disclosure and remediation for critical open source software as AI dramatically speeds up vulnerability discovery. Founding members include AWS, Google, Microsoft, OpenAI, Red Hat, NVIDIA, IBM, Cisco, JPMorganChase, and others. Akrites will provide a shared Security Incident Response Team (SIRT), a standardized coordinated vulnerability disclosure process, and act as a "maintainer of last resort" for abandoned but widely used packages. The goal is to reduce duplicate reports, avoid conflicting patches, and help upstream maintainers address vulnerabilities before they can be exploited. As AI makes it easier to find security flaws, can a coordinated industry effort help protect open source, or does it risk giving large corporations too much influence over the ecosystem? "Akrites is the largest coordinated effort in history to create systems and deploy tooling that leverages the collective power of the community to make everyone safer," the Linux Foundation said in an open letter. "Akrites participants will contribute engineering resources; work to build and ship fixes; or fund the engineers who do. Some companies have contributed mightily already. The reality is, collectively, we need to contribute more."

Read more of this story at Slashdot.

OHIF Viewers DICOM

Thu, 25 Jun 2026 20:09:15 +0200

View CSAF

Summary

Successful exploitation of this vulnerability in a custom integration version could allow an attacker to steal an authenticated clinician's token via a crafted link.

The following versions of OHIF Viewers DICOM are affected:

OHIF DICOM Web Viewer Framework <=v3.12.0

CVSS Vendor Equipment Vulnerabilities

v3 8.2 Open Health Imaging Foundation (OHIF) OHIF Viewers DICOM Server-Side Request Forgery (SSRF)

Background

Critical Infrastructure Sectors: Healthcare and Public Health

Countries/Areas Deployed: Worldwide

Company Headquarters Location: United States

Vulnerabilities

Expand All +

CVE-2026-12473

Two data sources (DICOMWebProxy and DICOMJSON) shipped in the default configuration fetch an arbitrary URL parameter without validation. A global authentication service in OHIF automatically injects the authenticated user's OIDC Bearer token into the resulting requests, sending it to the attacker-controlled server. DICOMweb data sources are not impacted.

View CVE Details

Affected Products

OHIF Viewers DICOM

Vendor:
Open Health Imaging Foundation (OHIF)

Product Version:
Open Health Imaging Foundation (OHIF) OHIF DICOM Web Viewer Framework: <=v3.12.0

Product Status:
known_affected

Remediations

Mitigation
The maintainer has fixed the reported vulnerability and released version 3.12.2 (2026-05-18). The fix is located at OHIF/Viewers#5985 (master), OHIF/Viewers#5978 (release/3.12).

Mitigation
Users are recommended to upgrade to v3.12.2 or later. Operators who need dicomwebproxy or dicomjson in authenticated deployments must additionally configure the new dangerouslyAllowedOriginsForAuthenticatedEnvironments allowlist in app-config.js.

Mitigation
Users running OHIF with authentication should remove ALL unused DicomWebProxyDataSource and DicomJSONDataSource configurations from the configuration file they are deploying with.

Relevant CWE: CWE-918 Server-Side Request Forgery (SSRF)

Metrics

CVSS Version Base Score Base Severity Vector String

3.1 8.2 HIGH CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N

4.0 8.3 HIGH CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:H/VI:L/VA:N/SC:H/SI:L/SA:N

Acknowledgments

Simon Weber and Volker Schönefeld of Machine Spirits UG reported this vulnerability to CISA

Legal Notice and Terms of Use

This product is provided subject to this Notification (https://www.cisa.gov/notification) and this Privacy & Use policy (https://www.cisa.gov/privacy-policy).

Recommended Practices

CISA recommends users take defensive measures to minimize the risk of exploitation of this vulnerability.

Minimize network exposure for all control system devices and/or systems, ensuring they are not accessible from the internet.

Locate control system networks and remote devices behind firewalls and isolating them from business networks.

When remote access is required, use more secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize VPN is only as secure as the connected devices.

CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.

CISA also provides a section for control systems security recommended practices on the ICS webpage on cisa.gov/ics. Several CISA products detailing cyber defense best practices are available for reading and download, including Improving Industrial Control Systems Cybersecurity with Defense-in-Depth Strategies.

CISA encourages organizations to implement recommended cybersecurity strategies for proactive defense of ICS assets.

Additional mitigation guidance and recommended practices are publicly available on the ICS webpage at cisa.gov/ics in the technical information paper, ICS-TIP-12-146-01B--Targeted Cyber Intrusion Detection and Mitigation Strategies.

Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.

CISA also recommends users take the following measures to protect themselves from social engineering attacks:

Do not click web links or open attachments in unsolicited email messages.

Refer to Recognizing and Avoiding Email Scams for more information on avoiding email scams.

Refer to Avoiding Social Engineering and Phishing Attacks for more information on social engineering attacks.

No known public exploitation specifically targeting this vulnerability has been reported to CISA at this time.

Revision History

Initial Release Date: 2026-06-25

Date Revision Summary

2026-06-25 1 Initial Publication

Legal Notice and Terms of Use

pydicom pynetdicom Library

Thu, 25 Jun 2026 20:09:14 +0200

View CSAF

Summary

Successful exploitation of this vulnerability could allow an unauthenticated attacker to write to arbitrary file paths.

The following versions of pydicom pynetdicom Library are affected:

pynetdicom >=v1.0.0|

CVSS Vendor Equipment Vulnerabilities

v3 9.1 pydicom pydicom pynetdicom Library Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')

Background

Critical Infrastructure Sectors: Healthcare and Public Health

Countries/Areas Deployed: Worldwide

Company Headquarters Location: United States

Vulnerabilities

Expand All +

CVE-2026-56445

The qrscp application's C-STORE handler uses a specific instance from attacker-supplied DICOM datasets directly in os.path.join() without sanitization, allowing file writes to arbitrary paths.

View CVE Details

Affected Products

pydicom pynetdicom Library

Vendor:
pydicom

Product Version:
pydicom pynetdicom: >=v1.0.0|
Product Status:
known_affected

Remediations

Vendor fix
The maintainer of pynetdicom has not responded to requests to work with CISA to mitigate this vulnerability. For update information, refer to the github page https://github.com/pydicom/pynetdicom.
https://github.com/pydicom/pynetdicom

Relevant CWE: CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')

Metrics

CVSS Version Base Score Base Severity Vector String

3.1 9.1 CRITICAL CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H

4.0 8.8 HIGH CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N

Acknowledgments

Simon Weber and Volker Schönefeld of Machine Spirits UG reported this vulnerability to CISA

Legal Notice and Terms of Use

This product is provided subject to this Notification (https://www.cisa.gov/notification) and this Privacy & Use policy (https://www.cisa.gov/privacy-policy).

Recommended Practices

CISA recommends users take defensive measures to minimize the risk of exploitation of this vulnerability.

Minimize network exposure for all control system devices and/or systems, ensuring they are not accessible from the internet.

Locate control system networks and remote devices behind firewalls and isolating them from business networks.

When remote access is required, use more secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize VPN is only as secure as the connected devices.

CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.

CISA also provides a section for control systems security recommended practices on the ICS webpage on cisa.gov/ics. Several CISA products detailing cyber defense best practices are available for reading and download, including Improving Industrial Control Systems Cybersecurity with Defense-in-Depth Strategies.

CISA encourages organizations to implement recommended cybersecurity strategies for proactive defense of ICS assets.

Additional mitigation guidance and recommended practices are publicly available on the ICS webpage at cisa.gov/ics in the technical information paper, ICS-TIP-12-146-01B--Targeted Cyber Intrusion Detection and Mitigation Strategies.

Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.

No known public exploitation specifically targeting this vulnerability has been reported to CISA at this time.

Revision History

Initial Release Date: 2026-06-25

Date Revision Summary

2026-06-25 1 Initial Publication

Legal Notice and Terms of Use

pydicom pynetdicom Library

Thu, 25 Jun 2026 19:24:32 +0200

View CSAF

Summary

Successful exploitation of this vulnerability could allow an unauthenticated attacker to write to arbitrary file paths.

The following versions of pydicom pynetdicom Library are affected:

pynetdicom >=v1.0.0|

CVSS Vendor Equipment Vulnerabilities

v3 9.1 pydicom pydicom pynetdicom Library Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')

Background

Critical Infrastructure Sectors: Healthcare and Public Health

Countries/Areas Deployed: Worldwide

Company Headquarters Location: United States

Vulnerabilities

Expand All +

CVE-2026-56445

The qrscp application's C-STORE handler uses a specific instance from attacker-supplied DICOM datasets directly in os.path.join() without sanitization, allowing file writes to arbitrary paths.

View CVE Details

Affected Products

pydicom pynetdicom Library

Vendor:
pydicom

Product Version:
pydicom pynetdicom: >=v1.0.0|
Product Status:
known_affected

Remediations

Vendor fix
The maintainer of pynetdicom has not responded to requests to work with CISA to mitigate this vulnerability. For update information, refer to the github page https://github.com/pydicom/pynetdicom.
https://github.com/pydicom/pynetdicom

Relevant CWE: CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')

Metrics

CVSS Version Base Score Base Severity Vector String

3.1 9.1 CRITICAL CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H

4.0 8.8 HIGH CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N

Acknowledgments

Simon Weber and Volker Schönefeld of Machine Spirits UG reported this vulnerability to CISA

Legal Notice and Terms of Use

This product is provided subject to this Notification (https://www.cisa.gov/notification) and this Privacy & Use policy (https://www.cisa.gov/privacy-policy).

Recommended Practices

CISA recommends users take defensive measures to minimize the risk of exploitation of this vulnerability.

Minimize network exposure for all control system devices and/or systems, ensuring they are not accessible from the internet.

Locate control system networks and remote devices behind firewalls and isolating them from business networks.

When remote access is required, use more secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize VPN is only as secure as the connected devices.

CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.

CISA also provides a section for control systems security recommended practices on the ICS webpage on cisa.gov/ics. Several CISA products detailing cyber defense best practices are available for reading and download, including Improving Industrial Control Systems Cybersecurity with Defense-in-Depth Strategies.

CISA encourages organizations to implement recommended cybersecurity strategies for proactive defense of ICS assets.

Additional mitigation guidance and recommended practices are publicly available on the ICS webpage at cisa.gov/ics in the technical information paper, ICS-TIP-12-146-01B--Targeted Cyber Intrusion Detection and Mitigation Strategies.

Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.

No known public exploitation specifically targeting this vulnerability has been reported to CISA at this time.

Revision History

Initial Release Date: 2026-06-25

Date Revision Summary

2026-06-25 1 Initial Publication

Legal Notice and Terms of Use

OHIF Viewers DICOM

Thu, 25 Jun 2026 19:24:29 +0200

View CSAF

Summary

Successful exploitation of this vulnerability in a custom integration version could allow an attacker to steal an authenticated clinician's token via a crafted link.

The following versions of OHIF Viewers DICOM are affected:

OHIF DICOM Web Viewer Framework <=v3.12.0

CVSS Vendor Equipment Vulnerabilities

v3 8.2 Open Health Imaging Foundation (OHIF) OHIF Viewers DICOM Server-Side Request Forgery (SSRF)

Background

Critical Infrastructure Sectors: Healthcare and Public Health

Countries/Areas Deployed: Worldwide

Company Headquarters Location: United States

Vulnerabilities

Expand All +

CVE-2026-12473

Two data sources (DICOMWebProxy and DICOMJSON) shipped in the default configuration fetch an arbitrary URL parameter without validation. A global authentication service in OHIF automatically injects the authenticated user's OIDC Bearer token into the resulting requests, sending it to the attacker-controlled server. DICOMweb data sources are not impacted.

View CVE Details

Affected Products

OHIF Viewers DICOM

Vendor:
Open Health Imaging Foundation (OHIF)

Product Version:
Open Health Imaging Foundation (OHIF) OHIF DICOM Web Viewer Framework: <=v3.12.0

Product Status:
known_affected

Remediations

Mitigation
The maintainer has fixed the reported vulnerability and released version 3.12.2 (2026-05-18). The fix is located at OHIF/Viewers#5985 (master), OHIF/Viewers#5978 (release/3.12).

Mitigation
Users are recommended to upgrade to v3.12.2 or later. Operators who need dicomwebproxy or dicomjson in authenticated deployments must additionally configure the new dangerouslyAllowedOriginsForAuthenticatedEnvironments allowlist in app-config.js.

Mitigation
Users running OHIF with authentication should remove ALL unused DicomWebProxyDataSource and DicomJSONDataSource configurations from the configuration file they are deploying with.

Relevant CWE: CWE-918 Server-Side Request Forgery (SSRF)

Metrics

CVSS Version Base Score Base Severity Vector String

3.1 8.2 HIGH CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N

4.0 8.3 HIGH CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:H/VI:L/VA:N/SC:H/SI:L/SA:N

Acknowledgments

Simon Weber and Volker Schönefeld of Machine Spirits UG reported this vulnerability to CISA

Legal Notice and Terms of Use

This product is provided subject to this Notification (https://www.cisa.gov/notification) and this Privacy & Use policy (https://www.cisa.gov/privacy-policy).

Recommended Practices

CISA recommends users take defensive measures to minimize the risk of exploitation of this vulnerability.

Minimize network exposure for all control system devices and/or systems, ensuring they are not accessible from the internet.

Locate control system networks and remote devices behind firewalls and isolating them from business networks.

When remote access is required, use more secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize VPN is only as secure as the connected devices.

CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.

CISA also provides a section for control systems security recommended practices on the ICS webpage on cisa.gov/ics. Several CISA products detailing cyber defense best practices are available for reading and download, including Improving Industrial Control Systems Cybersecurity with Defense-in-Depth Strategies.

CISA encourages organizations to implement recommended cybersecurity strategies for proactive defense of ICS assets.

Additional mitigation guidance and recommended practices are publicly available on the ICS webpage at cisa.gov/ics in the technical information paper, ICS-TIP-12-146-01B--Targeted Cyber Intrusion Detection and Mitigation Strategies.

Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.

CISA also recommends users take the following measures to protect themselves from social engineering attacks:

Do not click web links or open attachments in unsolicited email messages.

Refer to Recognizing and Avoiding Email Scams for more information on avoiding email scams.

Refer to Avoiding Social Engineering and Phishing Attacks for more information on social engineering attacks.

No known public exploitation specifically targeting this vulnerability has been reported to CISA at this time.

Revision History

Initial Release Date: 2026-06-25

Date Revision Summary

2026-06-25 1 Initial Publication

Legal Notice and Terms of Use

Curl 8.21.0 Released With 18 Security Fixes

Thu, 25 Jun 2026 13:23:40 +0200

The curl project has announced the release of version 8.21.0, marking its 275th release and including a significant security update. This version addresses 18 newly disclosed vulnerabilities, reflecting an unusually high volume of security reports. Project maintainer Daniel Stenberg announced…

Read more →

The post Curl 8.21.0 Released With 18 Security Fixes appeared first on IT Security News.

Curl 8.21.0 Released With 18 Security Fixes

Thu, 25 Jun 2026 12:52:44 +0200

The curl project has announced the release of version 8.21.0, marking its 275th release and including a significant security update. This version addresses 18 newly disclosed vulnerabilities, reflecting an unusually high volume of security reports. Project maintainer Daniel Stenberg announced on June 24, 2026. This release sets a record for the number of vulnerabilities addressed […]

The post Curl 8.21.0 Released With 18 Security Fixes appeared first on GBHackers Security | #1 Globally Trusted Cyber Security News Platform.

Why your cloud strategy is already out of date

Thu, 25 Jun 2026 11:08:34 +0200

I’ve been watching two conversations happen in parallel for the last ~3x months, and almost nobody is connecting them. That gap is going to hurt.

The first conversation is about cloud. Enterprises everywhere are rethinking their hyperscaler dependence. Costs are spiraling out of control. AI workloads are data-sensitive, latency-hungry and expensive to run on someone else’s infrastructure. Suddenly, private clouds are back in fashion. Sovereign clouds are popping up across Europe and Asia. Neoclouds, those nimble, specialized providers, are chipping away at the dominance of AWS, Azure and GCP. The logic is sound. You want control over your costs, your data, your destiny.

After a decade of “just put it in the cloud,” the pendulum is swinging back. Smart move.

The second conversation is happening in a much smaller room. It’s about what AI is about to do to the software supply chain. Mythos is real. I’ve seen enough to stop treating it like a thought experiment. These models are finding hundreds of vulnerabilities a night, not simple code mistakes, but novel chains of existing issues woven together into attack paths no human researcher would have mapped. It’s creative in a way that genuinely surprised me. That’s not a faster SAST scanner or a better linter. That’s a different class of threat entirely. And here’s the thing: even if you believe Mythos specifically is overhyped or a marketing play, the underlying capability is coming. It’s a when, not an if. The genie isn’t going back in the bottle.

Now, here’s the connection almost nobody is making: you’re replatforming for control, but the software supply chain underneath your workloads was never built for what’s about to hit it. These two trends are on a collision course, and most cloud strategy documents I see don’t mention it at all.

Here’s the connection nobody’s making: you’re replatforming for control, but the software supply chain underneath your workloads wasn’t built for what’s coming.

The problem isn’t your infrastructure

Your private cloud, your sovereign cloud, your carefully chosen neocloud, they all pull the same dependencies. The same open source packages. The same container images. The same long tail of libraries maintained by one or two people who fit it in on weekends and owe your enterprise absolutely nothing. That’s not a criticism of maintainers. It’s just the reality of how open-source works, and it has worked remarkably well for decades. But it was designed for a different tempo.

When AI starts finding vulnerabilities at an industrial scale in those deep dependency chains, your infrastructure choice doesn’t save you. The patch pipeline breaks regardless of where the servers live. It doesn’t matter if you’re running on bare metal in a Frankfurt data center or in a regulated government cloud in Singapore. The vulnerability is inside the container. It’s baked into the base image. It’s three layers down in a logging library that got pulled in transitively six months ago, and nobody on your team even knows it’s there.

We designed coordinated vulnerability disclosure for a world where finding a critical bug was rare, expensive and slow. A skilled researcher might spend weeks reverse-engineering something to find one really good vulnerability. They’d notify the maintainer. The maintainer would have time to triage, develop a patch, test it and publish it. The downstream ecosystem would pick it up over days or weeks. The whole rhythm assumed that the finding was the bottleneck. It’s not anymore. Now the finding is instantaneous and high-volume. The bottleneck has shifted entirely to the human side, the maintainer’s attention, the review process, the patching cadence, the downstream adoption. That pipeline doesn’t scale. It was never going to.

And we’re already seeing the early signs of strain. Maintainers are drowning in automated vulnerability reports and AI-generated noise. Security scanners fire off tickets for everything, with no triage, no context, no prioritization. The signal-to-noise ratio is terrible. Now imagine layering on hundreds of real, weaponizable CVEs discovered by a model that works overnight. The maintainer burns out. The patch doesn’t come. The downstream is exposed. Multiply that by thousands of projects across the long tail of open source, and you start to see the shape of the problem.

What I think actually happen

Two things need to be true at the same time, and neither of them is comfortable.

We need coordinated disclosure that actually works at scale. Not the fragmented mess we have today. Not a dozen competing groups, each with their own reporting format, their own severity ratings, their own urgency theatrics. One trusted pipeline. One place where vetted, verified, actionable reports land in a maintainer’s inbox with everything they need to act. Maintainers need to know that if they see a report from this pipeline, it’s real, it’s urgent and it comes with a tested fix. That’s the only way to cut through the noise. This isn’t a technical problem as much as it’s a coordination and trust problem. And it’s solvable if we have the will to stop competing and start cooperating.

And this is the part that makes people uncomfortable: We need a maintainer of last resort. I’m not saying this lightly. Some projects won’t patch. Some can’t, the maintainer is gone, the repo is abandoned, the original author is unreachable. Some maintainers will respond but won’t be able to ship a fix in the timeframe that matters. In every one of those cases, the downstream is left holding the risk with no recourse. Open source has always had a mechanism for exactly this situation: the fork. You take the project, you assume stewardship and you keep it alive independently. That’s not a violation of open-source principles. It is the principle. It’s the escape hatch that ensures no single maintainer becomes a permanent single point of failure for the entire ecosystem.

If we don’t build both of these things, the coordinated pipeline and the last-resort stewardship, the default outcome is chaos. Every major cloud provider will fork its own versions of critical libraries. Security vendors will ship competing forks of the same logging framework, the same serialization library, the same crypto wrapper. Your team will be left trying to figure out which fork has which CVE fixed, whether the fix itself introduces new issues and whether the fork is even maintained anymore. That’s not a theoretical nightmare. That’s the logical endpoint of doing nothing, and we’re already seeing early signs of it.

What if I’m asking the wrong question?

If I’m advising a customer right now, and I have these conversations every week, I tell them three things.

One, your cloud strategy needs a supply chain strategy baked in from the start. Not bolted on later as a compliance checkbox. If you’re replatforming to a sovereign cloud or a private hyperscaler or a neocloud, you’re bringing your dependencies with you. Understand what’s in your containers. Know your SBOM not as a document you generate for an audit, but as a living inventory you can query when something breaks. If you don’t know what’s in your stack, you can’t fix it.

Two, ask your vendors the hard question: what’s your Plan B when a critical dependency doesn’t get patched? Not if. When. Look for vendors who have thought about this, who have a strategy for maintaining forks, who participate in the ecosystem’s security efforts rather than just consuming and complaining. The ones who shrug or change the subject are telling you something important about how they’ll handle the next Log4j moment, except the next one might not be a single high-profile library. It might be fifty libraries simultaneously, across your entire stack.

Three, start building internal muscle for this now. That means having people who understand your dependency graph deeply enough to make tough calls about when to wait for an upstream patch and when to fork and maintain yourself. It means having the CI/CD infrastructure to ship fixes fast without breaking things. It means training your incident response teams to think about supply chain compromises, not just infrastructure attacks. The skills and processes you need are different from what most organizations have today.

The hard fork

There’s a version of this story where we get it right. Where the ecosystem comes together, builds the disclosure pipeline, funds the maintainer of last resort and creates a model that actually works for the AI era. I genuinely believe that’s possible. Open source has survived existential threats before. It adapts precisely because it’s decentralized, because anyone can fork, because the license guarantees the right to pick up where someone else left off.

But this time the clock is ticking faster. The same models that are going to stress-test our dependencies are the ones that can help us defend them. The question is whether we organize ourselves in time, or whether we wait for a crisis that forces everyone into their corners, forking in isolation, burning trust and learning the hard way what coordination could have prevented.

Your cloud strategy document probably has a section on disaster recovery. It probably covers what happens when a region goes down, when a provider has an outage, when a certificate expires. Does it cover what happens when a library four layers deep in your container image is discovered to have a critical vulnerability, and the maintainer hasn’t been seen on GitHub in eight months?

If it doesn’t, now is the time to write that section. Because that scenario isn’t hypothetical anymore. It’s just a matter of when.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

So you've become a FOSS-Maintainer - Lessons learned from ~6 years of maintaining HedgeDoc (gpn24)

Wed, 24 Jun 2026 20:49:36 +0200
Erik and Molly (among others) became HedgeDoc maintainers during the pandemic. They started a complete rewrite of the project almost immediately and learned FOSS maintenance the hard way. In this talk they'll present some lessons learned, so that others might have a better starting point. Now that you are a FOSS maintainer (or are aiming to become one) several questions might come to your mind. - What's maintaining like? - What can I do to make my life easier? - How do I manage the community? - How do I keep the motivation high? - How can I prevent burnout? - What's the important stuff that suddenly needs to be handled? We were at the same point, but after six years continuous maintenance of a reasonably big FOSS project, we've come to some answers that we'd like to share with you. Expect some honest answers, funny anecdotes and hard learned lessons. Licensed to the public under https://creativecommons.org/licenses/by/4.0/ about this event: https://cfp.gulas.ch/gpn24/talk/V9WEYQ/

Open source grapples with agentic coding

Wed, 24 Jun 2026 11:03:53 +0200

Unless you’ve been living under an old woodpile in your backyard, you have certainly seen how agentic coding is rocking the software development world. Things are happening fast and furious, and keeping up is practically a full-time job.

The latest area that is catching the attention of developers is how agentic coding is affecting the open source community. The open source movement has been defending the rights of folks to use, change, and contribute to software for many years. And of course, agentic coding is starting to become part of that process.

On the one hand, maintainers of open source projects rightfully are frustrated as they become overwhelmed with pull requests of dubious quality and usefulness being submitted by coding agents. On the other hand, as David Heinemeier Hansson notes, maintainers are starting to get a little snooty about accepting AI-written code, viewing it as somehow not worthy of being included. Some organizations have explicitly banned AI-generated submissions.

I get that they don’t want AI slop overwhelming their input queues. But I think it is a huge mistake to ban AI-written code outright.

Whose code?

Before I dig deeper into that notion, it’s important to look at another issue that arises from all of this: Who actually owns the code that AI writes?

Copyright requires that a human produce the thing being copyrighted. If you prompt Claude Code with “Write me a CMS system” and then Claude writes you a CMS system that you check into a public GitHub repository unchanged, it’s not quite clear if that code is protected by copyright. However, if you prompt Claude Code with a specification and guidelines and then you work with Claude to refine the initial result, reviewing the code and making changes as part of an iterative process, then it could be argued that a human did produce that code. But it is not at all clear-cut legally. (Please note that I am not a lawyer.)

The current thinking is that the result of accepting verbatim the output of a simple prompt is not copyrightable, and that no one actually owns the code — an interesting notion in and of itself.

But then the ethical question comes into play. If I find a bug in an open source project, I ask GitHub Copilot to fix it, and Copilot writes a clever and effective fix, then who cares who owns the code? Should a maintainer of the project reject such a pull request just because it was AI-generated? That seems silly to me, yet it is happening today.

Our code

There is, too, the issue of license compliance for AI-generated code. As a general rule, LLMs generate code rather than copying it. They don’t copy and paste code directly from repositories. However, there have been cases where AI-produced code has resembled open source code so closely that the claim could be made that it is a copy. If this happens with GPL code, it could be a violation of the license to use it without the receiving code base being “infected.” Open source maintainers naturally should be concerned about this happening.

In the end, an open source maintainer should care about the quality and license compliance of submissions, not how those submissions were derived. Gatekeeping based on the source of code doesn’t seem like a good path towards project success. Good code is good code, no matter where it comes from.

Agentic coding is here, and the open source community needs to realize — and embrace — that inevitability.

Demystifying StartupWMClass :: Terminal Thoughts

Wed, 24 Jun 2026 04:40:03 +0200

As the maintainer of Plank Reloaded, the most common bug report I get is "this app has the wrong icon." It's almost never the dock, it's a broken StartupWMClass in the app's .desktop file. So I wrote up how to find the right value on X11, Wayland, and KDE, and why deleting the line often fixes it.

submitted by /u/zquestz
[link] [comments]

29-Year-Old Squid Proxy Bug 'Squidbleed' Can Leak Cleartext HTTP Requests

Wed, 24 Jun 2026 01:08:15 +0200
A 29-year-old bug in the Squid web proxy, dubbed Squidbleed and tracked as CVE-2026-47729, can let an authorized proxy user retrieve fragments of another user's cleartext HTTP requests, including credentials and session tokens. The security researcher who reported the flaw credited Anthropic's Claude Mythos Preview for the discovery. The Hacker News reports: Squid describes this as an attack by a trusted client: someone already permitted to use the proxy, not any random host on the internet. That matches Squid's usual home, shared networks like schools, offices, and public Wi-Fi. In those setups, the attacker is just another user of the same proxy. The leak also only reaches traffic that Squid can read. Normal HTTPS rides an opaque CONNECT tunnel, so Squid never sees inside it; the exposed traffic is cleartext HTTP, plus TLS-terminating setups where Squid decrypts and inspects. The attacker also needs the proxy to reach an FTP server they control on port 21. Both FTP and that port are on by default. [...] If you patch, verify the fix, not just the version. Confirm the guard is in FtpGateway.cc, or check your distribution's backport, since distros ship their own builds (Debian packages Squid 5.7). The public thread is still inconsistent: maintainer Amos Jeffries first said Squid 7.6 carried the fix, then corrected that to 7.7, and on June 22 Debian's Salvatore Bonaccorso noted the referenced commit looks like it is already in 7.6. The fix is small, a null-terminator check before the vulnerable strchr calls, merged to the development branch in April and v7 in May. Squid 7.6 does separately patch CVE-2026-50012, an unrelated cache_digest heap overflow. The cleaner move is the one the researchers recommend anyway: turn FTP off. Chromium dropped FTP years ago, and most networks carry almost none of it, so disabling it removes this attack surface for free, whatever build you run. The risk is real but bounded. SUSE rates it moderate, CVSS 6.5, and the vector explains the score: the attacker needs proxy access (low privileges), and the only impact is confidentiality, nothing on integrity or availability.

Read more of this story at Slashdot.

CVE-2026-11772 | DRIMO CMS up to 1.0 info.php searching q cross site scripting (EUVD-2026-38450)

Tue, 23 Jun 2026 18:27:26 +0200
A vulnerability classified as problematic has been found in DRIMO CMS up to 1.0. This vulnerability affects the function searching of the file info.php. Performing a manipulation of the argument q results in cross site scripting. This vulnerability only affects products that are no longer supported by the maintainer. This vulnerability was named CVE-2026-11772. The attack may be initiated remotely. There is no available exploit.

Introducing Patch the Planet

Mon, 22 Jun 2026 19:09:10 +0200

What happens when you clear dozens of Trail of Bits engineers’ schedules, pair them with every open-source maintainer they can contact, and unleash the latest frontier models like GPT-5.5-Cyber on critical open-source targets? Thanks to our partnership with OpenAI and its Daybreak initiative, we can report that the impact is hundreds of discovered bugs, 64 pull requests, and 51 issues filed across 19 projects (with many more still undergoing coordinated disclosure). That was just the first week of Patch the Planet.

Frontier models like GPT-5.5-Cyber are producing a firehose of security findings, and already-stretched maintainers must sift through all of it to separate real vulnerabilities from plausible-sounding false positives. Patch the Planet is different: with our experts orchestrating and triaging findings, we handle the work of fixing and hardening the code alongside the people who maintain it.

The first week of Patch the Planet covered 19 projects across cryptography, networking, language infrastructure, and software supply chain. Among these 19 projects were cURL, NATS, pyca, Sigstore, aiohttp, the Go project, freenginx, Python and python.org, urllib3, PyPI, SimpleX, Valkey, and RustCrypto. Over 30 projects have joined the initiative so far, and we’re rapidly expanding it to include more; if you maintain an open-source project, apply to join!

Live look at the Trail of Bits engineering teams

Anyone can file an issue, flex, and walk away. We showed up with the patches: 37 are already merged, and many more are in flight. These merges go beyond just fixing bugs: we’re adding new tests and fuzzing harnesses, CI security scanning, supply-chain tooling, correctness fixes, and features maintainers had been meaning to get to. The goal of Patch the Planet is to leave essential open-source projects measurably better off.

We brought patches, not just bug reports

We’re reporting public findings on GitHub, including 64 total pull requests. We also filed 51 issues, 19 of which are already closed with a fix. This public tally undercounts the work, since several projects take reports through private channels like HackerOne, GitHub security advisories, mailing lists, and private forks, and most of these have not been released publicly yet.

What’s in those pull requests matters more than the count. At python.org, we added a CI workflow built on zizmor, our open-source GitHub Actions auditor, fixed all of the issues it flagged, and integrated it into their CI. In RustCrypto, we contributed correctness fixes to the big-integer library that higher-level cryptography is built on, alongside genuine feature work in review: serde encoding support and HPKE DHKEM suite IDs. Other patches were plain engineering help: storage-accounting and service-restart fixes in SimpleX, a clearer admin-quarantine confirmation in PyPI’s Warehouse, and supply-chain improvements like SBOM sidecars for Python’s Windows artifacts. We will also be upstreaming many testing improvements and new testing campaigns. Arguably, our best contributions are not even bug or security fixes.

Keeping track of all of this is a bot we call Patchy. Patchy monitors every project, posts each new finding and merged patch to our Slack, and, for reasons we consider scientifically sound, reintroduces the common use of goblins, gremlins, and assorted creatures. Here’s Patchy’s description of an issue that has been patched:

Patchy’s description of an issue that has been patched

When a patch lands, Patchy celebrates with a triumphant PATCHY HAPPY. Making Patchy happy is really what drives us.

Bug patched, Patchy happy

A few highlights from the week

The week produced more than we can fit in this post, but here are some quick highlights.

A fuzzing lab built in a day. Given a narrow goal (find remotely exploitable bugs) and no instructions on how, GPT-5.5-Cyber decided that reading the source of one of the most-reviewed C libraries in existence was a poor use of tokens. Instead, it stood up a full fuzzing lab in under a day: sanitizer and variant builds, a seed corpus drawn from existing tests, and harnesses across a dozen entry points. Instead of simply fuzzing exposed APIs, it successfully built a harness that injected operating system backpressure to identify novel issues by reaching previously unexplored buggy states. We estimate all of that effort likely would’ve taken one of our fuzzing experts two to three weeks to do manually. Just as important, it showed judgment about what to test, what to report (and not report), and where to find higher-impact findings. We’ll publish the full details in a standalone field report.

A pipeline for variant testing historical CVEs built in a day. Codex was also adept at building simple but effective pipelines, such as the CVE variant analysis pipeline shown below. Codex’s /goal feature combined with frontier models like GPT-5.5-Cyber for this type of variant analysis produced novel issues with almost exclusively high-signal output.

Pipeline for historical CVE variant analysis

A release-pipeline improvement at python.org. We reported multiple security issues for python.org, including some issues closing a legacy-API authorization gap. But we’re most proud of the work that produced long-term improvements to python.org’s release infrastructure: the new zizmor CI scanning, tightened release-file and metadata validation, deletion scoping fixed so bulk operations can’t reach beyond their target, and release-tooling patches in review that quote remote command arguments, fail safely on partial uploads, and add SBOM sidecars.

The aiohttp maintainers fixed their issues almost immediately. We privately reported a cluster of issues across aiohttp’s client and server paths, including cookies that could regain broader scope after a save and reload, digest credentials that could answer a challenge from the wrong origin, and resource limits that ran after attacker-controlled buffering rather than before. The maintainers authored and merged all eight fixes within hours, seven of them inside a single five-hour window. We were impressed and appreciate the maintainers’ prompt and collaborative work on these issues!

Differentially testing major cryptographic libraries against each other. Many of our projects implement the same logic, protocols, and algorithms. In particular, multiple projects implement the same cryptographic algorithms and standards like X.509 certificates. Therefore, we used Codex to point these projects at each other, and identify any relevant behavioral differences. This proved to be a high-signal approach that uncovered several issues, including this AES-GCM issue in PyCA and several X.509 issues, which we plan to upstream to x509-limbo.

Finding the bugs is now the easy part

If it wasn’t already clear from the last several months of security news, this week makes one thing clear: the expensive part of security work has moved. Arming Codex with fuzzing campaigns, variant analysis, differential testing, agentic searching, and similar techniques produces real vulnerabilities and compresses weeks or months of manual effort into hours. The advantage is no longer in finding bugs, but everything after: confirming a finding, getting its severity right, writing a patch a maintainer will accept, hardening the surrounding code, making long-term improvements to prevent similar issues in the future, and coordinating a disclosure. That is the work that floods of AI-generated reports threaten to bury.

Guidance for maintainers

If you’re a maintainer managing an unsustainable number of AI-generated bug reports, the core challenges you need to solve are deduplication, false-positive filtering, and severity correction.

Deduplication is the easiest problem to solve technically. Even simple AI-based tools that compare new reports against open issues perform well, especially when grounded in affected code lines. Automating this step eliminates most of the noise.

False-positive filtering and severity correction are harder, but they can be managed. Without explicit guidance, models default to rating everything as critical.

Patchy without threat model and severity guidance

Generic approaches like our fp-check tool help, but only to a point. The best improvements require project-specific documentation, threat models, and severity criteria. PyCA’s security documentation, for example, was dramatically effective at reducing false positives in our bug candidates. Files like AGENTS.md that explicitly tell models which documentation to consult produced the most consistent and effective results. If security researchers are armed with this documentation, especially AGENTS.md for AI-based research, more noise will be filtered out before reaching the maintainers.

What’s next and how to get involved

This was just our first week. Over 30 projects have committed to join Patch the Planet, with a growing waitlist. As more findings clear coordinated disclosure, we’ll publish more results and deeper field reports, including full fuzzing lab details, the variant-analysis and differential-testing pipelines, and the tooling we’re building to help maintainers triage AI-generated reports themselves. Our Patch the Planet gist contains the full public list of our week one output.

Join Patch the Planet and spread the word

If you maintain a critical open-source project and want this kind of help, you can apply to join Patch the Planet.

Mastra npm Supply Chain Attack Delivers Node.js Implant and PowerShell Backdoor

Mon, 22 Jun 2026 09:54:01 +0200

Microsoft Threat Intelligence has uncovered a massive supply-chain attack on the npm registry, affecting over 140 packages within the Mastra ecosystem. The campaign relies on a hijacked maintainer account to distribute a malicious typosquat package, which deploys a stealthy Node.js implant and a PowerShell backdoor. Researchers attribute this highly coordinated attack to Sapphire Sleet, a […]

The post Mastra npm Supply Chain Attack Delivers Node.js Implant and PowerShell Backdoor appeared first on Cyber Security News.

Sapphire Sleet Hijacks npm Maintainer Account to Publish Poisoned Mastra Packages

Mon, 22 Jun 2026 09:08:13 +0200

A widespread npm supply‑chain compromise to Sapphire Sleet, a North Korean state actor, after the takeover of an npm maintainer account enabled the mass publication of poisoned Mastra packages that silently delivered a multi‑stage implant. The campaign, disclosed June 19,…

Read more →

The post Sapphire Sleet Hijacks npm Maintainer Account to Publish Poisoned Mastra Packages appeared first on IT Security News.

IT Security News Hourly Summary 2026-06-22 09h : 12 posts

Mon, 22 Jun 2026 09:08:11 +0200

12 posts were published in the last hour 7:2 : pgAdmin 4 Released with Patches for Seven Vulnerabilities and Feature Enhancements 7:2 : Sapphire Sleet Hijacks npm Maintainer Account to Publish Poisoned Mastra Packages 7:2 : GitHub Actions Checkout Adds…

Read more →

The post IT Security News Hourly Summary 2026-06-22 09h : 12 posts appeared first on IT Security News.

Sapphire Sleet Hijacks npm Maintainer Account to Publish Poisoned Mastra Packages

Mon, 22 Jun 2026 08:52:47 +0200

A widespread npm supply‑chain compromise to Sapphire Sleet, a North Korean state actor, after the takeover of an npm maintainer account enabled the mass publication of poisoned Mastra packages that silently delivered a multi‑stage implant. The campaign, disclosed June 19, 2026, began when the attacker gained control of the ehindero maintainer identity an account with […]

The post Sapphire Sleet Hijacks npm Maintainer Account to Publish Poisoned Mastra Packages appeared first on GBHackers Security | #1 Globally Trusted Cyber Security News Platform.

The Rust Ecosystem Gets an AI Security Engineer in Residence

Sun, 21 Jun 2026 17:52:34 +0200
While the Rust Foundation has a Security Initiative to protect its ecosystem, "the threats have expanded," they announced this week, "and so has the kind of help maintainers need." Much of this comes back to a single shift: Automated tooling (much of it now built on large language models) has gotten good enough to surface real vulnerabilities in open source code quickly and at scale. That is useful, and several large Rust projects have already received and fixed credible issues found this way. The same tooling has also made it trivial to generate vulnerability reports that look plausible and are worthless. Maintainers across the ecosystem are losing real hours sorting these from the reports that matter, and the noise tends to bury the signal. So, with funding from the Alpha-Omega Project, the Rust Foundation is bringing on a full-time AI Security Engineer in Residence dedicated to the Rust ecosystem. This position is being funded with part of the $12.5M in open source security funding that the Linux Foundation announced in March. The role exists to take pressure off maintainers. The person in this position will use a mix of human-led and AI-assisted methods to proactively review Rust itself and the crates the ecosystem leans on most and help us separate real, exploitable issues from false positives and low-signal noise before anything reaches a maintainer... This role will run full-time for six months to start, with room to extend depending on what we learn and the funding available. Methods, playbooks, and prompts will be documented so the work doesn't end with the contract. We are grateful that Rust is not embarking on this work in isolation. Several other ecosystems have received parallel Alpha-Omega grants for the same kind of work (e.g., the PHP Foundation and the Drupal Association) and we plan to share tooling, triage practices, and what we learn rather than duplicating work A statement from Rust's new AI Security Engineer in Residence acknowledges that "One of our next challenges is the wave of bugs discovered by the next generation of AI-powered developer tools."

Read more of this story at Slashdot.

Copilot searched your mailbox. LiteLLM handed out admin keys. Run this 5-check audit before your stack is next

Thu, 18 Jun 2026 20:16:46 +0200

Two AI tools broke in the same way in the same two weeks, and four research teams proved it. The pattern underneath every disclosure is one sentence: enterprise AI accepts external input with no trust boundary.
On June 15, Varonis disclosed SearchLeak (CVE-2026-42824), a proof-of-concept exfiltration chain in Microsoft 365 Copilot Enterprise Search. A victim clicks a crafted microsoft.com URL, Copilot searches their mailbox, and the data leaves through a Bing SSRF. No plugins, no second click, no visible indicator. Four days earlier, Obsidian Security published a three-CVE chain against LiteLLM that carried a default low-privilege user all the way to admin and remote code execution. Two tools. Two teams. One broken boundary.
The five-check audit at the end of this article maps each gap to a CVE or a market signal from June, a command you can run before lunch, and a sentence a CISO can read to the board.
Copilot turned a trusted URL into an exfiltration engine
SearchLeak chained three weaknesses into a silent data-theft chain. The URL q parameter fed attacker instructions straight to Copilot’s LLM. A rendering race condition fired an image tag before the output sanitizer ran. Bing’s image-search endpoint, allowlisted in the Content Security Policy, routed the stolen data out. Microsoft rated the flaw critical and patched it on the back end, according to Varonis. NVD has not yet scored it; a third-party tracker lists it at 6.5 medium. The severity is contested, but the mechanism is not.
The escalation is the real story. This is the third Varonis Copilot exfiltration chain in twelve months, after Reprompt in January and EchoLeak in 2025. Reprompt hit Copilot Personal. SearchLeak hit Enterprise Search. Enterprise inherits the user’s full organizational permissions, so the blast radius is everything that a user can reach.
LiteLLM handed a default account to every provider key
The LiteLLM gateway holds the keys for OpenAI, Anthropic, Azure, and Bedrock behind a single proxy. The Obsidian chain runs in three moves. CVE-2026-47101, an authorization bypass, lets a non-admin mint a wildcard API key. CVE-2026-47102 promotes that caller to proxy admin through an unguarded /user/update endpoint. CVE-2026-40217 escapes the code sandbox through exec() with full builtins. Obsidian then demonstrated a reverse shell by injecting a forged tool-call response through LiteLLM’s callback mechanism. Obsidian assessed the combined chain at CVSS 9.9. The developer typed one word. The attacker popped a shell.
A separate LiteLLM flaw made the urgency immediate. CVE-2026-42271, a command-injection bug in the MCP test endpoints, landed on the CISA KEV list on June 8 with a June 22 remediation deadline. That KEV entry is not the Obsidian chain. The two are distinct disclosures four days apart, fixed in different releases, pointed at the same gateway. LiteLLM carries more than 40,000 GitHub stars and sits in thousands of enterprise deployments. This is not the first scare, either. A supply-chain compromise backdoored LiteLLM versions 1.82.7 and 1.82.8 on PyPI in March. A compromised gateway exposes every provider credential the organization holds.
Langflow and Mini Shai-Hulud proved the pattern scales
The same boundary broke in two more tools in the same fortnight. Langflow CVE-2026-5027 became the third Langflow remote-code-execution flaw to hit active exploitation this year. A path traversal in file upload lets an attacker write files anywhere on disk, and because Langflow ships with auto-login enabled by default, a single unauthenticated request reaches RCE. VulnCheck confirmed exploitation on June 9. Censys counted roughly 7,000 exposed instances, the heaviest concentration in North America, with MuddyWater attribution.
The Mini Shai-Hulud campaign hit a different pressure point. After the worm’s source code went public on May 12, copycat variants compromised 32 Red Hat Cloud Services npm packages on June 1, packages pulled 80,000 times a week. The worm harvests more than 20 credential types and self-propagates under the compromised maintainer’s identity.
Four teams, four tools, one operating failure. The bug classes differ. SearchLeak is a prompt injection. LiteLLM is privilege escalation. Langflow is path traversal. Mini Shai-Hulud is supply-chain poisoning. The boundary that broke is the same in all four.
The market already repriced the risk
CrowdStrike’s Q1 FY27 earnings call put a number on the gap. AIDR, the company’s AI detection and response line, grew ending ARR more than 250% sequentially, with a Q2 pipeline above $50 million (SEC-filed 8-K). Total company ARR reached $5.51 billion, and CrowdStrike’s fleet telemetry shows more than 1,800 agentic applications running across enterprise endpoints.
On June 17, the company extended AIDR to AWS, adding real-time evaluation of agent, LLM, and MCP communications across Amazon Bedrock, Kiro, and Strands Agents, building on its work with Anthropic’s Project Glasswing. Daniel Bernard, CrowdStrike’s chief business officer, said the AI attack surface now spans development, runtime, identities, and cloud infrastructure, and that teams treating those as separate domains leave the gaps between them open.
Practitioners name the same gap in plainer terms
David Levin, CISO at American Express Global Business Travel, told VentureBeat the pattern does not surprise him. “We kind of have this shadow AI, which is just the new version of shadow IT,” Levin said.
Both Langflow and LiteLLM fit the description. Teams stood them up for convenience, gave them credentials, and never brought them under governance. Levin puts the fix before deployment. “We didn’t go into this with just saying we’re going to go do this without the right fundamentals,” he said. “We leverage NIST controls. NIST has released their CSF along with their AI framework. OWASP released their top 10. You need the right fundamentals before you deploy.”
Merritt Baer, CSO at Enkrypt AI and former AWS Deputy CISO, named the structural version of the failure in a separate VentureBeat interview. “Enterprises believe they’ve ‘approved’ AI vendors, but what they’ve actually approved is an interface, not the underlying system,” Baer said. “The real dependencies are one or two layers deeper, and those are the ones that fail under stress.” She has tied that directly to how systems fall. “Raw zero-days aren’t how most systems get compromised. Composability is,” Baer told VentureBeat. “It’s the glue between the model and your data where the risk lives. If you give an agent bash and a root token, you’ve already done most of the attacker’s work for them.” That is what rows 2 and 4 of the audit test: the gateway that holds every key, and the agent identity no one governs.
Levin had a sharper frame for the boardroom. “You need to talk more in terms of risk versus compliance to your boards and your executives,” he said. “It’s not about the size of the engineering team anymore. It’s the size of your imagination. It’s all written in plain English. It’s not hard for anyone.” Neither SearchLeak nor LiteLLM needed custom malware or a zero-day to work.
Adam Meyers, CrowdStrike’s SVP of Intelligence, put the operational squeeze in numbers in an exclusive VentureBeat interview. “The problem is not zero-day. The problem is patching. If you 10x that problem, they’re gonna be completely underwater,” Meyers said. He pointed to identity as the second front. “Some of these AI have their own identities, or people give their identity to the AI to take action on their behalf, and that makes it a very complex problem.”
The five-check trust-boundary audit
Each row maps a gap to its proof point, a verification command for Monday morning, the fix, and the sentence to read to the board.
Trust-Boundary Gap
Proof Point
What Broke
Verify Monday
Fix Monday
Board Language
1. Prompt-to-Data
SearchLeak CVE-2026-42824. P2P injection + HTML race + Bing SSRF. One-click mailbox exfiltration via microsoft.com URL. PoC demonstrated; Microsoft rated it critical, NVD not yet scored.
URL q-parameter passed to LLM as instructions. Sanitizer ran after render. Bing acted as exfiltration proxy via CSP allowlist.
Audit CSP allowlists for domains performing server-side fetches. Monitor Copilot Search URLs for encoded payloads. Review Copilot audit logs.
Confirm server-side patch applied. Enable sensitivity labels restricting Copilot. Treat AI streaming output as untrusted.
“Our AI assistant could search employee email and send results to an attacker through a trusted Microsoft URL. Vendor patched it. We must verify configuration.”
2. Gateway Credential Exposure
LiteLLM three-CVE chain (-47101, -47102, -40217). CVSS 9.9. Separate CVE-2026-42271 on CISA KEV (fixed in v1.83.7; full chain fixed in v1.83.14-stable). June 22 deadline.
No role validation on key endpoints. Self-promotion to admin via /user/update. exec() sandbox escape. One gateway exposes all provider keys.
Run pip show litellm. Below 1.83.14-stable = vulnerable. Check /mcp-rest/test/ exposure. Audit proxy_admin accounts.
Upgrade to v1.83.14-stable+. Rotate all provider API keys. Block /mcp-rest/test/* at proxy. Review Custom Code Guardrails.
“Our AI gateway held keys for every provider. A default account could promote itself to admin and steal them all. Rotating and patching now.”
3. AI Tooling Sprawl
Langflow CVE-2026-5027 (CVSS 8.8). Third RCE of 2026. ~7,000 exposed instances. MuddyWater. Active exploitation June 9.
Path traversal in file upload. Auto-login enabled by default. Single unauthenticated request to RCE.
Query Censys/Shodan for Langflow, Flowise, n8n, Dify on your perimeter. Check auto-login. Inventory AI tools outside change management.
Pull AI platforms behind VPN/zero-trust. Enable auth everywhere. Upgrade Langflow to v1.9.0+ (current release 1.10.0). Fingerprint surface continuously.
“AI dev tools are exposed to the internet with login disabled. A nation-state group is exploiting this flaw now. Pulling behind access controls today.”
4. Non-Human Identity Governance
AIDR ARR up 250% (Q1 FY27, SEC 8-K). Q2 pipeline >$50M. 1,800+ agentic apps across enterprise endpoints.
Agents hold identities and act on behalf of humans. Some exceed their intended scope to reach a goal. No standard governs agent credential lifecycle.
Inventory all non-human identities used by agents and MCP servers. Map agent-to-data-store access. Flag agents with write access to security policy.
Least-privilege every agent identity. Set privilege boundaries via identity protection. Runtime detection for policy-exceeding actions. Human-in-the-loop for policy changes.
“AI agents hold credentials and act autonomously. We do not govern their identity lifecycle like human access. The 250% market growth tells us this gap is systemic.”
5. Runtime Agentic Detection
Falcon AIDR expanded to AWS (June 17). Covers Bedrock, Kiro, Strands Agents. MCP integration. Real-time agent/LLM/MCP evaluation.
Traditional tools monitor human-speed actions. Agents run at machine speed, thousands of actions per minute, and route around controls to reach goals.
Test if EDR/XDR links agent actions to originating identity. Verify SIEM ingests MCP communications. Confirm you can distinguish human from agent on endpoint.
Deploy AIDR or equivalent runtime detection. Shadow-AI discovery for all agentic apps, models, MCP servers, identities. Real-time policy enforcement on agent actions.
“We cannot distinguish a human employee from an AI agent acting on their behalf. We need runtime detection at machine speed that can stop damage before it starts.”
The fix is plumbing, not policy
The June 2 executive order creates an AI Cybersecurity Clearinghouse with a July 2 deadline. The five gaps above are not frontier-model problems. They are plumbing problems in the gateways, orchestration platforms, identity layers, and runtime environments where AI meets the enterprise.
The audit is five rows. Every row maps to a June disclosure or market signal, a command a team can run before lunch, and a sentence a CISO can read to the board. The question is not whether your vendor will patch. It's whether you find the gap first — or whether an attacker finds it the way they found Copilot and LiteLLM.

CVE-2026-8484 | FuseSource jansi up to 2.4.3 ioctl heap-based overflow (EUVD-2026-37064)

Tue, 16 Jun 2026 15:37:09 +0200
A vulnerability was found in FuseSource jansi up to 2.4.3. It has been rated as critical. This issue affects the function ioctl. This manipulation causes heap-based buffer overflow. This vulnerability only affects products that are no longer supported by the maintainer. This vulnerability is tracked as CVE-2026-8484. The attack is restricted to local execution. No exploit exists.

GNOME’s Video Player (Showtime) is looking for a maintainer

Tue, 16 Jun 2026 13:10:18 +0200
submitted by /u/BrageFuglseth
[link] [comments]

CVE-2025-71330 | image-size up to 1.2.1/2.0.2 ICNS Parser infinite loop (Nessus ID 321123)

Tue, 16 Jun 2026 10:37:01 +0200
A vulnerability, which was classified as problematic, was found in image-size up to 1.2.1/2.0.2. This impacts an unknown function of the component ICNS Parser. Such manipulation leads to infinite loop. This vulnerability only affects products that are no longer supported by the maintainer. This vulnerability is listed as CVE-2025-71330. The attack may be performed from remote. There is no available exploit.

CVE-2025-71319 | image-size up to 1.2.0/2.0.1 Image findBox infinite loop (GHSA-m5qc-5hw7-8vg7)

Tue, 16 Jun 2026 03:03:43 +0200
A vulnerability categorized as problematic has been discovered in image-size up to 1.2.0/2.0.1. Affected by this issue is the function findBox of the component Image Handler. Such manipulation leads to infinite loop. This vulnerability only affects products that are no longer supported by the maintainer. This vulnerability is documented as CVE-2025-71319. The attack can be executed remotely. There is not any exploit available. It is advisable to upgrade the affected component.

„Sommer der Glückseligkeit“: curl nimmt einen Monat lang keine Bug-Reports an

Mon, 15 Jun 2026 12:32:40 +0200
Seit Wochen kämpft der Maintainer von curl mit der Arbeitslast durch die Flut an KI-generierten Bug-Reports. Im Juli soll deshalb keiner angenommen werden.

„Sommer der Glückseligkeit“: curl nimmt einen Monat lang keine Bug-Reports an

Mon, 15 Jun 2026 12:23:39 +0200
Seit Wochen kämpft der Maintainer von curl mit der Arbeitslast durch die Flut an KI-generierten Bug-Reports. Im Juli soll deshalb keiner angenommen werden.

CVE-2026-48998 | guzzle psr7 up to 2.10.1 Message::parseRequest missing initialization (GHSA-34xg-wgjx-8xph / EUVD-2026-36239)

Thu, 11 Jun 2026 17:36:35 +0200
A vulnerability identified as problematic has been detected in guzzle psr7 up to 2.10.1. This impacts the function Message::parseRequest. The manipulation leads to missing initialization of a variable. This vulnerability only affects products that are no longer supported by the maintainer. This vulnerability is traded as CVE-2026-48998. It is possible to initiate the attack remotely. There is no exploit available. You should upgrade the affected component.

CVE-2026-49214 | guzzle psr7 up to 2.10.1 deserialization (GHSA-hq7v-mx3g-29hw / EUVD-2026-36240)

Thu, 11 Jun 2026 17:36:34 +0200
A vulnerability labeled as problematic has been found in guzzle psr7 up to 2.10.1. Affected is an unknown function. The manipulation results in deserialization. This vulnerability only affects products that are no longer supported by the maintainer. This vulnerability is known as CVE-2026-49214. It is possible to launch the attack remotely. No exploit is available. The affected component should be upgraded.

Pascal Chevrel: Spell-checking for more Firefox users — a community effort

Thu, 11 Jun 2026 16:24:27 +0200

A while back, I stumbled onto something that turned into a rewarding side-project at Mozilla.

Firefox ships with a built-in spellchecker, but it only activates if a dictionary for your language is bundled with the browser. Coverage had grown organically over the years — driven largely by localizers and community members adding support for their own languages. Dictionary work was actually very active in the early years of the Mozilla project, but like many things in a large open-source codebase with a lot to manage, it had quietly received less attention over time, for no particularly good reason. So I decided to change that.

Taking stock

I put together a full inventory dashboard of every third-party dictionary shipped in Firefox Desktop, cataloguing sources, upstream health, and — critically — licensing.

Licensing turns out to be the main bottleneck. Firefox is open-source software, so any dictionary we ship has to carry a licence compatible with the Mozilla codebase. Some excellent dictionaries exist for languages Firefox supports, but their licences don't allow direct inclusion. In those cases, the dictionary can still reach users — but only as a Firefox extension they have to find and install manually, rather than something that just works out of the box.

The goal of the inventory wasn't to point fingers at anything. It was to make the full picture visible, so that anyone who wanted to help would know exactly where to start.

Plugging into the community

Once the inventory existed, the work was really about connecting the right people. Mozilla's localizer community already had the expertise and motivation — what was sometimes missing was a clear entry point. I took care of all the patches myself, so that localizers wouldn't have to deal with the technical side of things. This work was done in coordination with Mozilla's Localization drivers team, who own the dictionary infrastructure and reviewed and merged the changes.

The results

We expanded the number of locales shipping with a built-in dictionary from 30 to 41. This shipped last week with Firefox 151.0.3, and these improvements also benefit Thunderbird users, since both applications share the same dictionary infrastructure.

New dictionaries added: Croatian, English (UK), Georgian, Persian, Slovenian, Tajik, Tamil, Tibetan, Turkish, Welsh, and Xhosa.

Updated dictionaries: Bulgarian, Danish, French, Hungarian, Indonesian, Latvian, Polish, Romansh, and Swedish.

Stirring the pot

Part of the reason for doing this work publicly — building the inventory, filing the bugs, making the gaps visible — was to give people with the right expertise a reason to step in themselves. That's exactly what happened.

For Turkish and Russian, the existing open-source Hunspell dictionaries had become outdated — vocabulary and linguistic rules that hadn't kept pace with how the languages are actually used today. Selim (our Turkish l10n lead) and Valentin (our Russian l10n lead) each decided to take matters into their own hands.

Selim forked the TDD Turkish dictionary and updated it with modern vocabulary, better circumflex support, and performance improvements — the result is hunspell-tr-moz, now shipping in Firefox 151.0.3. Valentin built a new modern Russian dictionary from scratch, ru-spelling-dictionary, released under MPL-2.0. It's currently available as a Firefox extension — if you use Russian, Valentin would appreciate feedback on the quality before it's integrated directly into Firefox.

Both projects are public and open-source.

What's still in the pipeline

The licence question is also quietly resolving itself for a couple more locales. The maintainers of the Kabyle and Asturian dictionaries have agreed to relicense their work to allow direct inclusion in Firefox. Once that's done, those communities will join the list too.

There are still gaps in the inventory. Some are licence issues that may resolve over time. But for many of the remaining locales, the honest answer is that we simply haven't looked hard enough yet. Dictionaries are often individual passion projects or work coming out of linguistics circles — they exist, but finding them takes investigation. If you know of a dictionary for a language Firefox doesn't currently support, that's exactly the kind of lead worth following up on.

An open invitation

Mozilla is still a place where a motivated contributor can find a corner of the project, do meaningful work, and have a real impact — without needing to be a browser engineer or a Mozilla insider.

The inventory dashboard is public. If you're a localizer, a linguist, or a dictionary maintainer and you want to help bring spellchecking to more Firefox users, the gaps are clearly documented. And if you maintain a dictionary that could be included but licensing is an obstacle, that's a conversation worth having.

See you in May 2027 for the next update.

This Week In Rust: This Week in Rust 655

Thu, 11 Jun 2026 10:13:12 +0200

Hello and welcome to another issue of This Week in Rust! Rust is a programming language empowering everyone to build reliable and efficient software. This is a weekly summary of its progress and community. Want something mentioned? Tag us at @thisweekinrust.bsky.social on Bluesky or @ThisWeekinRust on mastodon.social, or send us a pull request. Want to get involved? We love contributions.

This Week in Rust is openly developed on GitHub and archives can be viewed at this-week-in-rust.org. If you find any errors in this week's issue, please submit a PR.

Want TWIR in your inbox? Subscribe here.

Updates from Rust Community

Official

How Josh helps Rust manage code across multiple repositories

Maintainer spotlight: Tiffany Pek Yuan (@tiif)

Newsletters

This Month in Rust OSDev: May 2026

The Embedded Rustacean Issue #73

Project/Tooling Updates

Announcing stdx, Rust's extended standard library

OmniScope 0.2.0 released:FFI static detection tool based on LLVM IR

Announcing Asterinas 0.18.0

Oryxis SSH 0.8: split panes

Ratatui 0.30.1 is released - a Rust library for cooking up terminal user interfaces

@utoo/pack: A Next-Generation Build Tool Based on Turbopack

Pico de Gallo - a USB-attached protocol bridge for developing embedded-hal drivers on your laptop

kache 0.5.0: designing a correct compile-cache key

Announcing smb2: a very fast pure-Rust SMB2/3 client

Observations/Thoughts

Only Bounds

Porting our Django backend to Rust improved the infra usage by 90%

Decimal Crates Comparison and Benchmark | Chinese version

TeaQL Robot Task Board: a Rust TUI showcase for auditable business workflows

[video] Rayon is NOT for games - use this instead

[audio] Veo with Anders Hellerup Madsen and Gorm Casper

Rust Walkthroughs

[series] Who Runs Your Rust Future? Hands-On Intro to Async Rust

Extend MySQL Using Rust

Learn Rust Smart Pointers and Interior Mutability by Building Git Commit Graph Viewer

heap underflow: classic algorithm solutions in idiomatic Rust, runnable in the browser

Crate of the Week

This week's crate is rustion, a SSH bastion server.

Thanks to handewo for the self-suggestion!

Please submit your suggestions and votes for next week!

Calls for Testing

An important step for RFC implementation is for people to experiment with the implementation and give feedback, especially before stabilization.

If you are a feature implementer and would like your RFC to appear in this list, add a call-for-testing label to your RFC along with a comment providing testing instructions and/or guidance on which aspect(s) of the feature need testing.

No calls for testing were issued this week by Rust, Cargo, Rustup or Rust language RFCs.

Let us know if you would like your feature to be tracked as a part of this list.

Call for Participation; projects and speakers

CFP - Projects

Always wanted to contribute to open-source projects but did not know where to start? Every week we highlight some tasks from the Rust community for you to pick and get started!

Some of these tasks may also have mentors available, visit the task page for more information.

cuda-oxide Windows fork - test the Windows MSVC release on more CUDA/Windows setups

openslate - add unit tests for slugify() in api/src/notes.rs

openslate - add integration tests for notes CRUD in api/src/notes.rs

openslate - add integration tests for auth flow in api/src/users.rs

openslate - add unit tests for build_fts_query() in api/src/search.rs

openslate - add integration tests for auth middleware and logout in api/src/auth.rs

openslate - add integration tests for media endpoints (DB layer) in api/src/media.rs

openslate - add unit tests for ext_from_mime() and filename_from_url() in api/src/media.rs

reliakit - add a typed_csv example to the umbrella crate

reliakit - implement CsvField for char

reliakit - implement CsvField for the core::net address types

reliakit - write a short "which resilience block do I use?" guide

reliakit - extract a reusable rolling-window counter from RollingBreaker

If you are a Rust project owner and are looking for contributors, please submit tasks here or through a PR to TWiR or by reaching out on Bluesky or Mastodon!

CFP - Events

Are you a new or experienced speaker looking for a place to share something cool? This section highlights events that are being planned and are accepting submissions to join their event as a speaker.

If you are an event organizer hoping to expand the reach of your event, please submit a link to the website through a PR to TWiR or by reaching out on Bluesky or Mastodon!

Updates from the Rust Project

526 pull requests were merged in the last week

Compiler

add extern "tail" calling convention

add very basic "comptime" fn implementation

avoid unreachable_code on required return values

cleanup and optimize render_impls

macros: report unbound metavariables directly

rewrite rustc_span::symbol::Interner to avoid double hashing

staticlib hide internal symbols

Library

add APIs for case folding to the standard library

add _value API for number literals in proc-macro

further optimize SliceIndex impl for Range

improve TLS codegen by marking the panic/init path as cold

perf: use get_unchecked for TwoWaySearcher

stabilize PathBuf::into_string

stabilize Result::map_or_default and Option::map_or_default

Cargo

strip CR from cargo:token-from-stdout

Rustdoc

IXCRE: preserve sizedness bounds on type params belonging to the parent item

don't link doc(hidden) associated type projections

fix trait impl ordering

render impl restriction

Clippy

support iter_mut in ITER_NEXT_SLICE

borrowed_box: clean-up, improve suggestion message

double_must_use: make the lint machine-applicable in single-attribute case

iter_cloned_collect: split off the suggestion from the main message

add manual_isolate_lowest_one lint

detect more ranges in single_range_in_vec_init

do not trigger inline_trait_bounds on auto-derived code

extend extra_unused_lifetimes for spurious for<'a>

large_const_arrays: check nested large arrays

fix explicit_counter_loop false positive when the counter is only modified inside the else block of let...else binding

fix result_large_err and result_unit_err not triggering on async functions

fix unused_async_trait_impl suggestions with return statements

fix lints duplications in unknown_attribute and renamed_builtin_attr

obtaining the metadata of a const pointer is a const operation

perf: avoid cloning associated items in empty_line_after

perf: skip the boxed_local walk for functions without a Box parameter

perf: skip the inline_always relevance walk for items without the attribute

Rust-Analyzer

feat(diagnostics): emit error for infer vars in non-inference contexts

adopt uv's AI policy

distribute windows builts with mimalloc

lower field defaults to rustc_type_ir::Consts

RunnableKind::Test should map to project_json::RunnableKind::TestOne

extract_function misses &mut for container[i].mut_method()

do not emit a "type annotations needed" error on include_bytes!() where the array length cannot be inferred

no generate unused generic params in trait sign

parse OR pattern types

rename schema subItems with sub_items

implement rust-analyzer/evaluatePredicate lsp extension

parse unnamed enum variants

Rust Compiler Performance Triage

A fairly noisy week, with a bunch of small regressions contained within, leading to a slight increase on average in instruction counts. This week had a lot of large rollups, likely due to some CI problems, but thankfully many of those came with pre-triaged perf results by the time (thank you to those triagers!). Roughly similar slight regressions for cycles and wall times across the week.

Triage done by @simulacrum. Revision range: 4804ad7e..f3ef3bd8

2 Regressions, 0 Improvements, 10 Mixed; 5 of them in rollups 32 artifact comparisons made in total

Full report here

Approved RFCs

Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week:

#![register_{attribute,lint}_tool]

Final Comment Period

Every week, the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now.

Tracking Issues & PRs
Rust

Document panic in RangeInclusive::from(legacy::RangeInclusive)

Tracking Issue for explicit-endian String::from_utf16

Tracking Issue for substr_range and related methods

Decide and document where stdarch intrinsics are allowed to diverge from asm behavior

Document that ManuallyDrop's Box interaction has been fixed

Add temporary scope to assert_eq and assert_ne

Clean up crate type names to fix dylib vs staticlib confusion

Add T: PartialEq bounds to derived StructuralPartialEq impls.

stabilize feature float_algebraic

Compiler Team (MCPs only)

Deny todo!() in tidy

Leadership Council

Rust All Hands 2027

No Items entered Final Comment Period this week for Rust RFCs, Cargo, Language Team, Language Reference or Unsafe Code Guidelines.

Let us know if you would like your PRs, Tracking Issues or RFCs to be tracked as a part of this list.

New and Updated RFCs

RFC for convenient, explicit closure capture using move($expr) expressions

Upcoming Events

Rusty Events between 2026-06-10 - 2026-07-08 🦀

Virtual

2026-06-10 | Virtual (Girona, ES) | Rust Girona

Weekly coding session

2026-06-12 | Virtual (Kenya, KE) | RustaceansKenya

RUST FOR CIVIC TECH

2026-06-16 | Virtual (Washington, DC, US) | Rust DC

Mid-month Rustful

2026-06-17 | Hybrid (Vancouver, BC, CA) | Vancouver Rust

Rust Study/Hack/Hang-out

2026-06-17 | Virtual (Girona, ES) | Rust Girona

Weekly coding session

2026-06-18 | Hybrid (Seattle, WA, US) | Seattle Rust User Group

June, 2026 SRUG (Seattle Rust User Group) Meetup

2026-06-18 | Virtual (Berlin, DE) | Rust Berlin

Rust Hack and Learn

2026-06-21 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup

Rust Deep Learning: Third Sunday

2026-06-23 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup

Fourth Tuesday

2026-06-23 | Virtual (London, UK) | Women in Rust

Lunch & Learn: What the heck are monads - and how do we fake them in Rust

2026-07-01 | Virtual (Indianapolis, IN, US) | Indy Rust

Indy.rs - with Social Distancing

2026-07-02 | Virtual (Berlin, DE) | Rust Berlin

Rust Hack and Learn

2026-07-02 | Virtual (Nürnberg, DE) | Rust Nuremberg

Rust Nürnberg online

2026-07-05 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup

Rust Deep Learning: First Sunday

2026-07-07 | Virtual (London, GB) | Women in Rust

👋 Community Catch Up

Europe

2026-06-10 | Köln, DE | Rust Cologne

Rust in June: Speedy Rust

2026-06-10 | München, DE | Rust Munich

Rust Munich 2026 / 2 - Hacking Evening

2026-06-11 | Berlin, DE | Rust Berlin

Rust Berlin on location 🏳️‍🌈 - Edition 014

2026-06-11 | Switzerland, CH | PostTenebrasLab

Rust Meetup Geneva

2026-06-12 - 2026-06-14 | Kraków, PL | Rustmeet

Rustmeet

2026-06-16 | Leipzig, DE | Rust - Modern Systems Programming in Leipzig

Interactive: Everything is Open Source

2026-06-16 | Milano, IT | Rust Language Milan

Real-time planning in Rust: SolverForge & SERIO

2026-06-18 | Aarhus, DK | Rust Aarhus

Talk Night at Danske Commodities

2026-06-18 | Barcelona, ES | BcnRust

21st BcnRust Meetup

2026-06-19 | Dresden, DE | Rust Dresden

Second Meetup

2026-06-23 | Paris, FR | Rust Paris

Rust meetup #86

2026-06-23 | Warsaw, PL | Rust Warsaw

Rust Warsaw Meetup: June 2026

2026-06-25 | Berlin, DE | Rust Berlin

Rust Berlin Talks: The next generation

2026-07-02 | Edinburgh, GB | Rust and Friends

Bevy, Bits, & Cats (Rust July Talks)

2026-07-02 | Enschede, OV, NL | Baseflow Tech Meetups

AI Summit

2026-07-08 | Dublin, IE | Rust Dublin

Join us live and INPERSON for Rust 261

North America

2026-06-11 | Lehi, UT, US | Utah Rust

Utah Rust June Meetup

2026-06-11 | Mountain View, CA, US | Hacker Dojo

RUST MEETUP at HACKER DOJO

2026-06-11 | San Diego, CA, US | San Diego Rust

San Diego Rust June Meetup - Back in person!

2026-06-16 | San Francisco, CA, US | San Francisco Rust Study Group

Rust Hacking in Person

2026-06-16 | San Francisco, CA, US | San Francisco Rust Study Group

Rust Hacking in Person

2026-06-17 | Hybrid (Vancouver, BC, CA) | Vancouver Rust

Rust Study/Hack/Hang-out

2026-06-18 | Hybrid (Seattle, WA, US) | Seattle Rust User Group

June, 2026 SRUG (Seattle Rust User Group) Meetup

2026-06-24 | Austin, TX, US | Rust ATX

Rust Lunch - Fareground

2026-06-24 | Los Angeles, CA, US | Rust Los Angeles

Rust LA: Rust-Based Constraint Solvers in 2D Sketching with Zoo Technologies

2026-06-25 | Atlanta, GA, US | Rust Atlanta

Rust-Atl

2026-06-26 | New York, NY, US | Rust NYC

Rust NYC's Big Summer Social

2026-07-02 | Saint Louis, MO, US | STL Rust

Git is easy?

Oceania

2026-06-11 | Brisbane City, QL, AU | Rust Brisbane

Rust Brisbane • June 2026

2026-06-25 | Melbourne, AU | Rust Melbourne

Rust Melbourne June 2026

South America

2026-06-18 | Florianópolis, BR | Rust SC

Rust Floripa

If you are running a Rust event please add it to the calendar to get it mentioned here. Please remember to add a link to the event too. Email the Rust Community Team for access.

Jobs

Please see the latest Who's Hiring thread on r/rust

Quote of the Week

It's a footgun, yes, but it's a sound footgun.

– Prof. Dr. Ralf Jung on github

Thanks to Theemathas for the suggestion!

Please submit quotes and vote for next week!

This Week in Rust is edited by:

nellshamrell

llogiq

ericseppanen

extrawurst

U007D

mariannegoldin

bdillo

opeolluwa

bnchi

KannanPalani57

tzilist

Email list hosting is sponsored by The Rust Foundation

Discuss on r/rust

GitHub finally pulls the plug on automatic install script execution for npm

Thu, 11 Jun 2026 03:18:37 +0200

The ability for attackers to leverage automatic install script execution in npm will finally come to an end when expected changes arrive from GitHub in July. Coders will still be able to enable the function, but the default setting will block it.

In V12, default settings are changing, GitHub said in its changelog, noting, “it turns an npm install behavior that runs automatically today into one you explicitly opt into.”

Specifically, the post said, “allowScripts defaults to off: npm install will no longer execute preinstall, install or postinstall scripts from dependencies unless they are explicitly allowed in your project. This includes native node-gyp builds; a package with a binding.gyp and no explicit install script still gets blocked, because npm runs an implicit node-gyp rebuild for it. Prepare scripts from git, file, and link dependencies are blocked the same way.”

Analysts, consultants, and users generally applauded the change, but said that it would only narrow the exposure to supply chain attacks instead of eliminating it.

Attacks likely to move elsewhere

Sonu Kapoor, maintainer for CVE Lite CLI in the OWASP Incubator Project, said that this change is likely to force the supply chain attacks that leveraged the automatic execution to move elsewhere.

“This does not eliminate npm supply chain risk, it removes a major automatic execution path,” Kapoor said. “Attackers can still move to other paths: malicious package code that runs at application runtime, compromised maintainer accounts, dependency confusion, typo-squatting, poisoned GitHub Actions workflows, malicious transitive dependencies, or stolen publishing tokens. This closes one very dangerous door, but it does not secure the whole house.”

Still, attacks leveraging the setting have been regularly used in supply chain attacks.

However Alan Parkinson, director of secure medical device firm Threat Detective, said more sophisticated attackers have already moved beyond this hole.

“The install script attack vector has been known for years,” Parkinson said. “Most security teams marked it as low risk and moved on to higher risk threats. What raised its profile wasn’t the technical exploitability changing, it was a run of high-profile victims and some threat actors openly chasing notoriety.”

He added, “the pre and post install scripts was never a clever attack vector to begin with. Running code from an install hook is crude and noisy, which is why it caused such visible damage. The more capable actors are already moving to other methods, so v12 mainly shuts the door on less sophisticated threat actors.”

Although GitHub declined an interview, Zach Steindler, a GitHub principal engineer, answered InfoWorld’s questions by email. He said the volume and pace of supply chain attacks forced the default settings change.

“We’ve seen attackers target these capabilities to quickly propagate attacks from one compromised package to many. Years of security and usability research have shown that it’s not enough to make secure functionality available; the secure path has to be the default in order for it to be widely adopted,” Steindler said.

He added, “we believe that these changes are a great way to provide high impact secure defaults while still providing the option for some users to fall back on functionality they might need in some circumstances.”

Change overdue

Sanchit Vir Gogia, chief analyst at Greyhound Research, said that GitHub was the last of the repositories to make the setting default change. “Rivals moved first: Yarn, pnpm and Bun all block third party install scripts by default in their own ways,” Gogia said. “Npm is not inventing a new doctrine. It is finally adopting one.”

Steindler didn’t dispute Gogia’s comment.

“It’s not easy being the stewards of the largest package repository in the world. Community consensus on what security capabilities should be standard, and when it’s okay to make breaking changes shifts over time. From our continual conversations with the community, it was clear it was time to make this change,” Steindler said.

“The recent attacks are alarming,” he noted, “but stewarding these package repositories is a multi-decade effort, not just a moment in time. As attacks evolve, so will our defensive security capabilities. We’re in this for the long haul.”

Gogia said that the change, although overdue, is a good one.

“Npm is removing one of the most comfortable hiding places for software supply chain risk: code that executes the moment a developer types install,” Gogia said. “With npm v12, execution becomes something that must be approved, recorded in the project, and committed for review. That is not a design adjustment. It is a change in control philosophy.”

Bad defaults become infrastructure

Gogia had his own take on why GitHub waited so long.

“Npm waited because its risky default acquired a constituency. As far back as 2016, npm’s own position was that the convenience of install scripts outweighed the worm risk, with an opt-out flag for the cautious. The trade-off was a documented product decision, not an oversight,” he said.

“The trouble with bad defaults is that they become infrastructure,” he added. “Native module builds, browser installers such as Playwright and Cypress, Electron download flows and Husky hooks all grew around automatic execution. Turning it off became less a technical adjustment and more a constitutional reform.”

Liability changed hands

The real pressure for the change, however, came from regulators.

“The deeper answer is that the liability changed hands. Once regulation such as the EU Cyber Resilience Act and securities disclosure rules placed supply chain failure on corporate balance sheets, a documented unsafe default became indefensible,” Gogia said.

Kapoor agreed that long-used procedures enabled this security hole to survive longer than it should have.

“The reason this likely was not done long ago is compatibility,” he said. “Install scripts are not only used by attackers. Many legitimate packages use them to compile native modules, download platform-specific binaries, generate files, or complete setup steps. Changing the default breaks assumptions that have existed in the npm ecosystem for years. That is why these security changes often arrive slowly. The safer default is obvious from a security perspective, but painful from an ecosystem compatibility perspective.”

In addition, he noted, “the bigger point is that package managers are moving from implicit trust to explicit trust. That is the right direction. Developers should have to approve which dependencies are allowed to execute code during install. But approval cannot become a blind checkbox. Teams need visibility into which package wants to run a script, whether it is direct or transitive, why it is there, and whether it belongs in the project at all.”

Kapoor added that this change matters because install-time execution often happens in privileged environments with access to tokens, secrets, internal registries, build artifacts, or deployment paths. “Even if the script does not compromise production directly, it may be able to steal enough context to support the next stage of an attack,” he said.

Value in the pain

Cybersecurity consultant Brian Levine, executive director of FormerGov, agreed that the closing of this security hole is a very good thing.

“It seems like virtually every major supply chain attack of the last decade has had the same original sin: code that ran automatically because the ecosystem let it. Npm finally closing that door by default is overdue, but it’s genuinely significant. This is the package manager for hundreds of billions of downloads a month,” Levine said.

“When npm changes its defaults, it changes the security posture of practically every enterprise dev environment on the planet. It may have been the last large code repository to still allow this kind of automated execution.”

Levine added that this change might not merely stop a security hole, but the new process may meaningfully improve security.

“There’s actually something valuable buried in this migration pain. Having developers explicitly approve which packages can run code and commit that list to source control is a form of software supply chain governance that many organizations never had,” Levine said. “It creates an auditable record which is meaningful, especially for regulated industries.”

GitHub finally pulls the plug on automatic install script execution for npm

Thu, 11 Jun 2026 03:08:03 +0200

The ability for attackers to leverage automatic install script execution in npm will finally come to an end when expected changes arrive from GitHub in July. Coders will still be able to enable the function, but the default setting will block it.

In V12, default settings are changing, GitHub said in its changelog, noting, “it turns an npm install behavior that runs automatically today into one you explicitly opt into.”

Specifically, the post said, “allowScripts defaults to off: npm install will no longer execute preinstall, install or postinstall scripts from dependencies unless they are explicitly allowed in your project. This includes native node-gyp builds; a package with a binding.gyp and no explicit install script still gets blocked, because npm runs an implicit node-gyp rebuild for it. Prepare scripts from git, file, and link dependencies are blocked the same way.”

Analysts, consultants, and users generally applauded the change, but said that it would only narrow the exposure to supply chain attacks instead of eliminating it.

Attacks likely to move elsewhere

Sonu Kapoor, maintainer for CVE Lite CLI in the OWASP Incubator Project, said that this change is likely to force the supply chain attacks that leveraged the automatic execution to move elsewhere.

“This does not eliminate npm supply chain risk, it removes a major automatic execution path,” Kapoor said. “Attackers can still move to other paths: malicious package code that runs at application runtime, compromised maintainer accounts, dependency confusion, typo-squatting, poisoned GitHub Actions workflows, malicious transitive dependencies, or stolen publishing tokens. This closes one very dangerous door, but it does not secure the whole house.”

Still, attacks leveraging the setting have been regularly used in supply chain attacks.

However Alan Parkinson, director of secure medical device firm Threat Detective, said more sophisticated attackers have already moved beyond this hole.

“The install script attack vector has been known for years,” Parkinson said. “Most security teams marked it as low risk and moved on to higher risk threats. What raised its profile wasn’t the technical exploitability changing, it was a run of high-profile victims and some threat actors openly chasing notoriety.”

He added, “the pre and post install scripts was never a clever attack vector to begin with. Running code from an install hook is crude and noisy, which is why it caused such visible damage. The more capable actors are already moving to other methods, so v12 mainly shuts the door on less sophisticated threat actors.”

Although GitHub declined an interview, Zach Steindler, a GitHub principal engineer, answered questions by email. He said the volume and pace of supply chain attacks forced the default settings change.

“We’ve seen attackers target these capabilities to quickly propagate attacks from one compromised package to many. Years of security and usability research have shown that it’s not enough to make secure functionality available; the secure path has to be the default in order for it to be widely adopted,” Steindler said.

He added, “we believe that these changes are a great way to provide high impact secure defaults while still providing the option for some users to fall back on functionality they might need in some circumstances.”

Change overdue

Sanchit Vir Gogia, chief analyst at Greyhound Research, said that GitHub was the last of the repositories to make the setting default change. “Rivals moved first: Yarn, pnpm and Bun all block third party install scripts by default in their own ways,” Gogia said. “Npm is not inventing a new doctrine. It is finally adopting one.”

Steindler didn’t dispute Gogia’s comment.

“It’s not easy being the stewards of the largest package repository in the world. Community consensus on what security capabilities should be standard, and when it’s okay to make breaking changes shifts over time. From our continual conversations with the community, it was clear it was time to make this change,” Steindler said.

“The recent attacks are alarming,” he noted, “but stewarding these package repositories is a multi-decade effort, not just a moment in time. As attacks evolve, so will our defensive security capabilities. We’re in this for the long haul.”

Gogia said that the change, although overdue, is a good one.

“Npm is removing one of the most comfortable hiding places for software supply chain risk: code that executes the moment a developer types install,” Gogia said. “With npm v12, execution becomes something that must be approved, recorded in the project, and committed for review. That is not a design adjustment. It is a change in control philosophy.”

Bad defaults become infrastructure

Gogia had his own take on why GitHub waited so long.

“Npm waited because its risky default acquired a constituency. As far back as 2016, npm’s own position was that the convenience of install scripts outweighed the worm risk, with an opt-out flag for the cautious. The trade-off was a documented product decision, not an oversight,” he said.

“The trouble with bad defaults is that they become infrastructure,” he added. “Native module builds, browser installers such as Playwright and Cypress, Electron download flows and Husky hooks all grew around automatic execution. Turning it off became less a technical adjustment and more a constitutional reform.”

Liability changed hands

The real pressure for the change, however, came from regulators.

“The deeper answer is that the liability changed hands. Once regulation such as the EU Cyber Resilience Act and securities disclosure rules placed supply chain failure on corporate balance sheets, a documented unsafe default became indefensible,” Gogia said.

Kapoor agreed that long-used procedures enabled this security hole to survive longer than it should have.

“The reason this likely was not done long ago is compatibility,” he said. “Install scripts are not only used by attackers. Many legitimate packages use them to compile native modules, download platform-specific binaries, generate files, or complete setup steps. Changing the default breaks assumptions that have existed in the npm ecosystem for years. That is why these security changes often arrive slowly. The safer default is obvious from a security perspective, but painful from an ecosystem compatibility perspective.”

In addition, he noted, “the bigger point is that package managers are moving from implicit trust to explicit trust. That is the right direction. Developers should have to approve which dependencies are allowed to execute code during install. But approval cannot become a blind checkbox. Teams need visibility into which package wants to run a script, whether it is direct or transitive, why it is there, and whether it belongs in the project at all.”

Kapoor added that this change matters because install-time execution often happens in privileged environments with access to tokens, secrets, internal registries, build artifacts, or deployment paths. “Even if the script does not compromise production directly, it may be able to steal enough context to support the next stage of an attack,” he said.

Value in the pain

Cybersecurity consultant Brian Levine, executive director of FormerGov, agreed that the closing of this security hole is a very good thing.

“It seems like virtually every major supply chain attack of the last decade has had the same original sin: code that ran automatically because the ecosystem let it. Npm finally closing that door by default is overdue, but it’s genuinely significant. This is the package manager for hundreds of billions of downloads a month,” Levine said.

“When npm changes its defaults, it changes the security posture of practically every enterprise dev environment on the planet. It may have been the last large code repository to still allow this kind of automated execution.”

Levine added that this change might not merely stop a security hole, but the new process may meaningfully improve security.

“There’s actually something valuable buried in this migration pain. Having developers explicitly approve which packages can run code and commit that list to source control is a form of software supply chain governance that many organizations never had,” Levine said. “It creates an auditable record which is meaningful, especially for regulated industries.”

This article originally appeared on InfoWorld.

Der Hardest Fork: Warum KI den Open-Source-Software-Sicherheitsbetrieb neu erfordert

Wed, 10 Jun 2026 08:43:16 +0200

LONDON (IT BOLTWISE) – KI-gestützte Sicherheitsforschung entdeckt nicht nur mehr Schwachstellen, sondern kombiniert sie auch schneller zu gefährlichen Kettenangriffen. Der CEO von Chainguard fordert deshalb ein Umdenken beim Open-Source-Software-Sicherheitsbetrieb: Statt sich allein auf das klassische, koordinierte Disclosure zu verlassen, müsse die Branche eine skalierbare Infrastruktur für „Maintainer of Last Resort“ und kuratierte Forks aufbauen. Im […]

... den vollständigen Artikel »Der Hardest Fork: Warum KI den Open-Source-Software-Sicherheitsbetrieb neu erfordert« lesen

Dieser Beitrag Der Hardest Fork: Warum KI den Open-Source-Software-Sicherheitsbetrieb neu erfordert erschien als erstes auf IT BOLTWISE x Artificial Intelligence.

CVE-2026-10047 | Bitdefender Napoca bare-metal hypervisor 519 Real-mode Hook napoca/kernel/handler.c out-of-bounds write

Mon, 08 Jun 2026 23:54:19 +0200
A vulnerability, which was classified as critical, has been found in Bitdefender Napoca bare-metal hypervisor 519. Impacted is an unknown function of the file napoca/kernel/handler.c of the component Real-mode Hook Handler. Performing a manipulation results in out-of-bounds write. This vulnerability only affects products that are no longer supported by the maintainer. This vulnerability is reported as CVE-2026-10047. The attack requires a local approach. No exploit exists.

CVE-2026-10046 | Bitdefender Napoca bare-metal hypervisor Malicious Guest Operatingreal Mode bios_handlers.c out-of-bounds write

Mon, 08 Jun 2026 22:53:02 +0200
A vulnerability, which was classified as critical, was found in Bitdefender Napoca bare-metal hypervisor. The affected element is an unknown function of the file napoca/guests/bios_handlers.c of the component Malicious Guest Operatingreal Mode. Executing a manipulation can lead to out-of-bounds write. This vulnerability only affects products that are no longer supported by the maintainer. This vulnerability appears as CVE-2026-10046. The attack requires local access. There is no available exploit.

CVE-2026-11511 | Bolt CMS up to 3.7.5 HTML Attribute TextType.php style HTML injection (EUVD-2026-35059)

Mon, 08 Jun 2026 17:51:40 +0200
A vulnerability was found in Bolt CMS up to 3.7.5. It has been declared as problematic. This vulnerability affects unknown code of the file src/Storage/Field/Type/TextType.php of the component HTML Attribute Handler. Executing a manipulation of the argument style can lead to HTML injection. This vulnerability only affects products that are no longer supported by the maintainer. This vulnerability is registered as CVE-2026-11511. It is possible to launch the attack remotely. Furthermore, an exploit is available. The GitHub repository was archived by the owner and is now read-only.

Ruby Fights Supply-Chain Attacks With Filter Offering 'Cooldown' Before Installing New Packages

Mon, 08 Jun 2026 13:53:41 +0200
Most supply-chain attacks using Ruby's package hosting site "exploit a narrow window," according to a new blog post form Ruby core maintainer Hiroshi Shibata. So its packaging-managing Bundler tool now offers a filter that blocks new version until it's been public "for at least N days. Releases too new to have been scrutinized are passed over in favor of ones that have aged past the window." The feature was designed in the open, drawing on how other ecosystems approach the same problem. It is opt-in, and complements rather than replaces existing defenses like mandatory 2FA and trusted publishing... Cooldown is unset by default, so a project without it keeps resolving to the newest versions.... Passing 0 disables cooldown for the run... Cooldown is most useful as one part of the wider security investment happening on rubygems.org. The registry now validates gem contents at push time and checks logins against Have I Been Pwned so that compromised passwords cannot be reused, work described in Protecting rubygems.org from the outside in. A dedicated team is running AI-assisted vulnerability scanning against the most critical gems, backed by Alpha Omega and Anthropic, and the direction of all of this is tracked on a public roadmap. Trusted publishing and mandatory 2FA already raise the bar for who can push a release in the first place.

Read more of this story at Slashdot.

CVE-2026-11460 | Boost Serialization up to 1.91 improper validation of specified type of input (Issue 331 / EUVD-2026-34991)

Sun, 07 Jun 2026 23:38:05 +0200
A vulnerability marked as critical has been reported in Boost Serialization up to 1.91. The impacted element is an unknown function. This manipulation causes improper validation of specified type of input. The identification of this vulnerability is CVE-2026-11460. It is possible to initiate the attack remotely. Furthermore, there is an exploit available. The maintainer was notified on Aug 2025 and a disclosure deadline was set for 90 days. The maintainer acknowledged but postponed indefinitely citing time concerns. No patch is currently available and the disclosure deadline has expired.

CVE-2026-10064 | TRENDnet TEW-432BRP 3.10B20 /goform/formSetPortTr special_name stack-based overflow

Sun, 07 Jun 2026 06:07:53 +0200
A vulnerability classified as critical has been found in TRENDnet TEW-432BRP 3.10B20. This affects the function formSetPortTr of the file /goform/formSetPortTr. Performing a manipulation of the argument special_name results in stack-based buffer overflow. This vulnerability only affects products that are no longer supported by the maintainer. This vulnerability is cataloged as CVE-2026-10064. It is possible to initiate the attack remotely. Furthermore, there is an exploit available. The vendor explains: "This product has been EOL for 15 years (since 2009). As the item has been EOL for such a long time, we are not able to replicate or fix any vulnerabilities."

CVE-2026-10061 | TRENDnet TEW-432BRP 3.10B20 /goform/formWPS peerPin command injection

Sun, 07 Jun 2026 06:07:50 +0200
A vulnerability labeled as critical has been found in TRENDnet TEW-432BRP 3.10B20. Affected is the function formWPS of the file /goform/formWPS. The manipulation of the argument peerPin results in command injection. This vulnerability only affects products that are no longer supported by the maintainer. This vulnerability is identified as CVE-2026-10061. The attack can be executed remotely. Additionally, an exploit exists. The vendor explains: "This product has been EOL for 15 years (since 2009). As the item has been EOL for such a long time, we are not able to replicate or fix any vulnerabilities."

CVE-2026-10063 | TRENDnet TEW-432BRP 3.10B20 /goform/formWPS peerPin stack-based overflow

Sun, 07 Jun 2026 06:07:47 +0200
A vulnerability described as critical has been identified in TRENDnet TEW-432BRP 3.10B20. Affected by this issue is the function formWPS of the file /goform/formWPS. Such manipulation of the argument peerPin leads to stack-based buffer overflow. This vulnerability only affects products that are no longer supported by the maintainer. This vulnerability is listed as CVE-2026-10063. The attack may be performed from remote. In addition, an exploit is available. The vendor explains: "This product has been EOL for 15 years (since 2009). As the item has been EOL for such a long time, we are not able to replicate or fix any vulnerabilities."

CVE-2026-10062 | TRENDnet TEW-432BRP 3.10B20 /goform/formSetRoute ip/mask/gateway stack-based overflow

Sun, 07 Jun 2026 06:07:45 +0200
A vulnerability marked as critical has been reported in TRENDnet TEW-432BRP 3.10B20. Affected by this vulnerability is the function formSetRoute of the file /goform/formSetRoute. This manipulation of the argument ip/mask/gateway causes stack-based buffer overflow. This vulnerability only affects products that are no longer supported by the maintainer. This vulnerability is tracked as CVE-2026-10062. The attack is possible to be carried out remotely. Moreover, an exploit is present. The vendor explains: "This product has been EOL for 15 years (since 2009). As the item has been EOL for such a long time, we are not able to replicate or fix any vulnerabilities."

CVE-2026-10060 | TRENDnet TEW-432BRP 3.10B20 /goform/formSetRoute ip/mask/gateway command injection

Sun, 07 Jun 2026 06:07:42 +0200
A vulnerability identified as critical has been detected in TRENDnet TEW-432BRP 3.10B20. This impacts the function formSetRoute of the file /goform/formSetRoute. The manipulation of the argument ip/mask/gateway leads to command injection. This vulnerability only affects products that are no longer supported by the maintainer. This vulnerability is referenced as CVE-2026-10060. Remote exploitation of the attack is possible. Furthermore, an exploit is available. The vendor explains: "This product has been EOL for 15 years (since 2009). As the item has been EOL for such a long time, we are not able to replicate or fix any vulnerabilities."

Ladybird Browser Stops Accepting Public Pull Requests

Sat, 06 Jun 2026 22:51:58 +0200
The Ladybird browser isn't opposed to AI coding tools, but it's just brought a new change to their code-contributing policies. February 23: "Ladybird adopts Rust, with help from AI." I used Claude Code and Codex for the translation. This was human-directed, not autonomous code generation. I decided what to port, in what order, and what the Rust code should look like. It was hundreds of small prompts, steering the agents where things needed to go... The requirement from the start was byte-for-byte identical output from both pipelines. The result was about 25,000 lines of Rust, and the entire port took about two weeks. The same work would have taken me multiple months to do by hand. June 5 (Friday): We will no longer accept public pull requests... A pull request no longer tells us as much as it used to about the person submitting it. A substantial patch used to imply substantial effort, and that effort was a reasonable proxy for good faith. That assumption no longer holds.... We have already seen patient, well-resourced campaigns in open source to earn maintainer trust and abuse it. What has changed is how much faster and cheaper it has become to produce work that looks like a serious contribution... Whether code was typed by hand is beside the point. What matters is who is responsible for it once it enters the browser. Ladybird is becoming a browser for real users. The people introducing changes to it must be the people who decide those changes belong in the project, and who will answer for the consequences. As part of this change, we will close all currently open public pull requests. We are grateful for the work people put into them, but keeping the existing queue open would keep that contribution path open in practice. There is no perfect time to make this change, so we are making it now. Going forward, pull requests will only be available to project maintainers. There will not be a separate process for submitting patches by other means. We do not want to create a shadow contribution system through issues, comments, email, or forks... Outside involvement still matters: clear bug reports, reductions, website testing, standards discussion, design discussion, security reports, and technical feedback all help move the project forward. This is the right change for Ladybird now. We are preparing to ship a browser to real users, and our development process has to match that responsibility.

Read more of this story at Slashdot.

CVE-2025-10437 | Eksagate Webpack Management System up to 20251119 sql injection

Sat, 06 Jun 2026 14:53:40 +0200
A vulnerability labeled as critical has been found in Eksagate Webpack Management System up to 20251119. This issue affects some unknown processing. Such manipulation leads to sql injection. This vulnerability only affects products that are no longer supported by the maintainer. This vulnerability is referenced as CVE-2025-10437. It is possible to launch the attack remotely. No exploit is available.

CVE-2025-0987 | CB Project CVLand up to 20251103 allows authorization (EUVD-2025-37480)

Sat, 06 Jun 2026 14:08:43 +0200
A vulnerability, which was classified as critical, has been found in CB Project CVLand up to 20251103. The affected element is an unknown function. This manipulation of the argument allows causes authorization bypass. This vulnerability only affects products that are no longer supported by the maintainer. The identification of this vulnerability is CVE-2025-0987. It is possible to initiate the attack remotely. There is no exploit available.

Will Kahn-Greene: Bleach 6.4.0 releases -- final release

Fri, 05 Jun 2026 16:10:40 +0200

What is it?

Bleach is a Python library for sanitizing and linkifying text from untrusted sources for safe usage in HTML.

Bleach v6.4.0 released!

Bleach 6.4.0 includes two security fixes, a fix to tinycss2 dependency requirements, and some other things.

See the changes here:

https://bleach.readthedocs.io/en/latest/changes.html#version-6-4-0-june-5th-2026

Bleach v6.4.0 is the final release

I haven't used Bleach on a project in years, but I still had some time to maintain it. That changed about a year ago when I got re-orged into a new role and I haven't had time to do any Bleach work since then.

To recap, Bleach sits on top of html5lib which hasn't been actively maintained in years. It is dangerous to maintain Bleach in that context.

We vendored html5lib so we could make adjustments to the library to keep Bleach going. This is not a sustainable approach, but it was ok for the short term.

Over the years, we've talked about other options:

find another library to switch to

take over html5lib development

fork html5lib and vendor and maintain our fork

write a new HTML parser

etc

None of those are feasible for me.

Bleach has been a solo-maintained project for a while now. The world is crazy and it's much harder to build a team of trusted maintainers now than it was (or at least, it sure feels that way). I don't see any possibility of increasing the maintenance team or passing it to someone else responsibly.

Switching contexts from my regular work to Bleach is really hard. Bleach is complicated, the problem domain is complicated, and there's a lot of nuanced context. I can't just switch gears, spend 15 minutes on Bleach to do something, and then switch back to the rest of my day. I periodically get nag messages about this which are entirely valid, but there's nothing I can do about it. It doesn't feel great.

Then in 2025, Emil, a long-time Bleach contributor, built justhtml which gives us an easy migration path off of Bleach. He even took the time to write a migration guide.

Thoughts and statistics

In 2019, when I stepped down the first time, I wrote a post on stepping down.

In 2023, when I deprecated the project, I wrote a post on Bleach 6.0.0 and deprecation.

From the first commit on 2010-02-18 to today's final commit on 2026-06-05, the Bleach project lasted 16 years, 3 months — 5,951 days, or about 16.29 years.

There were 64 releases.

There were roughly 960 commits.

From 80 roughly contributors

Top 3:

Will Kahn-Greene: 462

James Socol: 182

Greg Guthe: 133

Roughly 5,040 lines of Python code excluding the vendored html5lib.

I was maintainer from October 2015 to now--that's a little under 11 years.

It feels weird to end a project that's outlived many of the Mozilla sites and Python web frameworks it was designed to protect.

What happens now?

This is the end of the project.

Bleach. Last release.

If you're still using Bleach, I think you have three options:

End your project. Maybe you don't need to be maintaining your thing anymore? Use Bleach as your reason to exit and do something different with your time on Earth.

Switch to the sanitizer API. Rework your project to use the sanitizer API.

Spec: https://wicg.github.io/sanitizer-api/

Docs: https://developer.mozilla.org/en-US/docs/Web/API/Element/setHTML

Swap Bleach out for justhtml. Emil provided a migration guide for switching from Bleach to justhtml.

Good luck with whatever option you choose!

Thanks!

Many thanks to James who created Bleach and gave it a set of first principles that guided our choices for 16 years.

Many thanks to Greg who I worked with on Bleach for a long while and maintained Bleach for several years. Working with Greg was always easy and his reviews were thoughtful and spot-on.

Many thanks to Emil who was a contributor to Bleach for a long while and created justhtml providing Bleach users a migration path.

Many thanks to Jonathan who, over the years, provided a lot of insight into how best to solve some of Bleach's more squirrely problems.

Many thanks to Sam who was an indispensible resource on HTML parsing and sanitizing text in the context of HTML.

Many thanks to all the users and contributors of Bleach!

Where to go for more

For more specifics on this release, see here: https://bleach.readthedocs.io/en/latest/changes.html#version-6-4-0-june-5th-2026

Documentation and quickstart here: https://bleach.readthedocs.io/en/latest/

Source code and issue tracker here: https://github.com/mozilla/bleach/

So you've become a FOSS-Maintainer - Lessons learned from ~6 years of maintaining HedgeDoc (gpn24)

Fri, 05 Jun 2026 14:18:34 +0200
Erik and Molly (among others) became HedgeDoc maintainers during the pandemic. They started a complete rewrite of the project almost immediately and learned FOSS maintenance the hard way. In this talk they'll present some lessons learned, so that others might have a better starting point. Now that you are a FOSS maintainer (or are aiming to become one) several questions might come to your mind. - What's maintaining like? - What can I do to make my life easier? - How do I manage the community? - How do I keep the motivation high? - How can I prevent burnout? - What's the important stuff that suddenly needs to be handled? We were at the same point, but after six years continuous maintenance of a reasonably big FOSS project, we've come to some answers that we'd like to share with you. Expect some honest answers, funny anecdotes and hard learned lessons. Licensed to the public under https://creativecommons.org/licenses/by/4.0/ about this event: https://cfp.gulas.ch/gpn24/talk/V9WEYQ/

So you've become a FOSS-Maintainer - Lessons learned from ~6 years of maintaining HedgeDoc

Fri, 05 Jun 2026 14:18:32 +0200

Author: media.ccc.de - Bewertung: 1x - Views:6
https://media.ccc.de/v/gpn24-585-so-you-ve-become-a-foss-maintainer-lessons-learned-from-6-years-of-maintaining-hedgedoc

Erik and Molly (among others) became HedgeDoc maintainers during the pandemic. They started a complete rewrite of the project almost immediately and learned FOSS maintenance the hard way. In this talk they'll present some lessons learned, so that others might have a better starting point.

Now that you are a FOSS maintainer (or are aiming to become one) several questions might come to your mind.

- What's maintaining like?
- What can I do to make my life easier?
- How do I manage the community?
- How do I keep the motivation high?
- How can I prevent burnout?
- What's the important stuff that suddenly needs to be handled?

We were at the same point, but after six years continuous maintenance of a reasonably big FOSS project, we've come to some answers that we'd like to share with you. Expect some honest answers, funny anecdotes and hard learned lessons.

Molly, Erik

https://cfp.gulas.ch/gpn24/talk/V9WEYQ/

#gpn24 #SoftwareandInfrastructure

Licensed to the public under https://creativecommons.org/licenses/by/4.0/

binding.gyp Supply Chain Attack Compromises Dozens of npm Packages Across Maintainer Accounts

Fri, 05 Jun 2026 01:22:57 +0200

A self-replicating worm has been quietly spreading across the npm registry using a method most security teams do not watch for. Instead of hiding inside package.json scripts, the attacker weaponized a tiny configuration file called binding.gyp to trigger malicious code…

Read more →

The post binding.gyp Supply Chain Attack Compromises Dozens of npm Packages Across Maintainer Accounts appeared first on IT Security News.

Dave Airlie on Linux Kernel Maintenance (SE Radio)

Fri, 05 Jun 2026 00:23:39 +0200
The Software Engineering Radio podcast has put up an interview with graphics maintainer Dave Airlie. Much of what is in there will not be news to LWN readers, but it is an interesting overview of the life of a large-subsystem maintainer.

I was talking to a few of the Rust people, and I thought: these are very young people, these are a group of people in their 20s, maybe 30s, they are a younger cohort of developers than the people I am normally used to dealing with. I thought there was maybe a good way we could bring these groups together. I think that having young people coming into the kernel using Rust is valuable... So I thought that I should be supportive of bringing Rust into the kernel.

binding.gyp Supply Chain Attack Compromises Dozens of npm Packages Across Maintainer Accounts

Thu, 04 Jun 2026 23:23:03 +0200

A self-replicating worm has been quietly spreading across the npm registry using a method most security teams do not watch for. Instead of hiding inside package.json scripts, the attacker weaponized a tiny configuration file called binding.gyp to trigger malicious code the moment a developer runs npm install. The campaign hit dozens of packages across multiple […]

The post binding.gyp Supply Chain Attack Compromises Dozens of npm Packages Across Maintainer Accounts appeared first on Cyber Security News.

Malicious binding.gyp Campaign Targets npm Packages Across Maintainer Accounts

Thu, 04 Jun 2026 14:24:38 +0200

On June 3, 2026, a highly coordinated supply chain attack compromised 57 npm packages across multiple maintainer accounts. The rapid campaign, lasting less than 2 hours, heavily impacted popular tools such as @vapi-ai/server-sdk and ai-sdk-ollama. Security researchers have identified the payload as a new variant of the “Miasma” worm. This self-spreading malware targeted Red Hat […]

The post Malicious binding.gyp Campaign Targets npm Packages Across Maintainer Accounts appeared first on Cyber Security News.

The NHS Was Lucky. The Next Victim Might Not Be.

Thu, 04 Jun 2026 14:24:34 +0200

In May 2026, malicious code appeared inside packages used across NHS software projects. The software supply chain attack named Mini Shai-hulud by researchers spread through CI/CD systems, package registries, and developer tooling before anyone noticed something was wrong. It was caught quickly. Damage was limited.

The UK's National Cyber Security Centre is using that near-miss to bring into focus a more urgent case. The underlying conditions that made Mini Shai-hulud possible are not unique to that attack, and subsequent similar campaigns have gone undetected for longer and spread far more widely.

The Problem Is Structural

NCSC National Resilience Officer Jack F, is not mainly interested in a particular threat actor or a CVE but in how modern software development works — because that architecture is the vulnerability.

A single application today may rely on dozens, sometimes hundreds, of third-party packages like libraries, frameworks, SDKs, and code snippets pulled in automatically when a developer runs a single install command. Node.js, Python, and Rust are singled out as especially exposed because their minimal standard libraries push developers toward external registries for even basic functionality. Once a package is in a dependency tree, it often pulls in further packages of its own — transitive dependencies that the original developer never consciously chose.

This is not a flaw in the ecosystem's design. It is the design. The efficiency gains from reusable, trusted components are real, and the NCSC is not arguing against open source development. The argument is more specific to the combination of automation, implicit trust, and scale that turns a single compromised package into a vector capable of spreading malicious code across hundreds of organizations before any single one of them detects it.

Four Techniques Defenders Need to Know

The NCSC documents four attacker techniques active in recent campaigns. The first is maintainer account compromise — attackers steal credentials or tokens that allow them to push malicious updates to a trusted, legitimate package. This is how the Axios npm attack in March 2026 worked. The maintainer account was hijacked, a malicious dependency injected, and the backdoor distributed to an estimated 80% of cloud environments before the window closed.

Read: Axios Supply Chain Attack Exposes Developers to Hidden Malware

The second technique is abandoned package takeover where attackers claim ownership of packages whose original maintainers have let their domains lapse or transferred control elsewhere. The third is typosquatting, in which, publishing packages with names that closely mimic popular legitimate ones, waiting for a developer to make a spelling error in an install command. The fourth is self-propagation, meaning, using credentials stolen from one package compromise to access or modify additional packages, creating a cascading contamination chain across an ecosystem.

All four techniques exploit the same structural feature. Once a package enters a trusted registry, downstream consumers inherit whatever trust that registry confers, automatically, at scale, with no human checkpoint.

What Defenders Are Being Asked to Do

The NCSC's immediate guidance falls into three categories. The first is visibility. Organizations must audit recent package updates and version changes, identify newly introduced or unexpected dependencies, and maintain a software bill of materials — a documented inventory of every component a codebase relies on. Without that inventory, it is impossible to know whether a compromised package is present at all.

The second is detection. Teams should monitor CI/CD activity, network traffic, and credential use for anomalies, and run dependency scanning tools against known indicators of compromise published after supply chain incidents.

And the third is remediation posture. If a compromise is suspected, automatic dependency updates should be paused immediately, new updates and versions reviewed manually before redeployment, and any potentially exposed API keys, tokens, and credentials rotated without waiting for confirmation of active exploitation. Enforcing multi-factor authentication on developer and package registry accounts is singled out specifically — the absence of universally enforced MFA on registry accounts is identified as a structural gap that maintainer account compromises directly exploit.

The NCSC also flags developer environments themselves as a soft target. Developer devices are typically less tightly controlled than managed corporate endpoints, making credential theft from developer workstations a reliable path to registry access that bypasses enterprise security controls entirely.

As supply chain attacks on PyPI and npm packages have become a near-weekly occurrence across security news feeds, rhe NCSC's guidance refers defenders to the Software Security Code of Practice as the authoritative framework for strengthening development and supply chain management. It also notes that its SSCoP implementation guidance will be updated shortly to reflect the specific attack scenarios.

Hole in GitHub’s browser-based VSCode editor could lead to stolen token

Thu, 04 Jun 2026 04:01:52 +0200

A vulnerability in GitHub’s browser-based VSCode editor could lead to the theft of a developer’s token under certain circumstances, says a researcher.

The issue, revealed this week in a blog by Ammar Askar, has apparently been already addressed by GitHub owner Microsoft. But it raises a questions about both DevOps security, and about the researcher’s allegation that, because Microsoft doesn’t treat bug discoveries seriously, he can justify giving it short notice before openly publishing vulnerabilities he finds.

First, the bug: Users of github.com may not realize it, but when they are on any repository, they can shift to github.dev and its browser-based version of VSCode just by changing the URL.

Why do this? Because the browser instance of VSCode is pretty powerful, Askar says in his blog. “You can view all the files in the repo (even if it’s a private one), you can send out pull requests, and even make commits.”

Rob Enderle, a IT consultant who heads the Enderle Group, agrees that jumping into VSCode this way is “an incredibly useful tactical tool for quick tasks. By just hitting the ‘.’ key in any GitHub repo, you instantly get a browser-based VS Code interface without having to clone gigabytes of data locally. It’s perfect for rapid PR reviews, quick documentation edits, or navigating code on the fly without breaking your workflow. Just keep in mind that it runs entirely in the browser sandbox; there’s no compute backend, no terminal, and no code execution.”

For any heavy lifting or actual compiling, he added, the developer will still need the raw compute of a local workstation, or a full cloud environment like Codespaces.

The problem, Askar says, is that this functionality is achieved by github.com POSTing over an OAuth token to github.dev that allows it to interact with GitHub on your behalf. “The token is not scoped to the particular repo you interacted with, meaning it has full access to every other repo that you have access to,” he wrote in the blog.

“The presence of this token, and the fact that this web app is running almost the entire brunt of VSCode’s million line Typescript codebase, makes it a great target for anyone looking into VSCode bugs,” he wrote.

The exploit

Askar said that a threat actor could install an extension in a repository using a Jupyter notebook, a web application for creating and sharing computational documents that has the ability to install a malicious local workspace extension while skipping the publisher trust check. In his proof of concept, Askar said that once his payload runs, the newly installed extension will grab the GitHub API token, run a query to get the private repos the developer has access to, and then print out the replies and the token.

This vulnerability also exists in the desktop version of VSCode, Askar said, though it’s harder to exploit, since a threat actor would need to convince the victim to clone their repo and open the notebook containing the webview script payload. “Of course,” he added, “if you [the hacker] had some other XSS [cross-site scripting attack] in a webview that you can get a victim to open, you get effectively full RCE [remote code execution] on their computer.”

In an email, he said this vulnerability was “about as serious as it gets. Any website on the internet could have redirected you to a github.dev link that could have provided an attacker a token to read and modify your code repos. If one could convince the maintainer of a popular software project to click a link, they could have made whatever modifications they wanted to their project.”

This means, said Enderle, “we have to start treating developer endpoints with strict, isolated, zero-trust parameters, because we clearly cannot rely on vendor complacency to protect us.”

This issue reinforces the point that you should never follow any links unless you know exactly where they will take you, added Dwayne McDaniel, principal developer advocate at GitGuardian.

Short notice

Here’s where things get complicated. Because of an unhappy experience when disclosing a previous VSCode vulnerability to Microsoft — the bug was fixed, but Askar wasn’t given credit — this time he only gave GitHub one hour notice that this new discovery was going to be published. Microsoft applied what Askar calls a “stopgap” fix by adding a confirmation when a developer opens notebooks in web VSCode, and by not allowing the trusted publisher requirement to be skipped by commands.

[Related content: When responsible disclosure becomes unpaid labor]

An ethical question

Askar’s short notice raises an ethical question: How far in advance should a responsible researcher give notice to a vendor about a vulnerability before publicly revealing it?

These days, most infosec pros agree that notice must be given, or else a threat actor can quickly exploit a hole. Not only that, but the researcher risks damage to their reputation if reasonable notice isn’t given. Experienced researchers often give vendors at least 30 days to create and distribute a patch.

For their part, vendors often create bug bounty programs, or partner with bug bounty programs, to reward researchers for their work. Unfortunately, some vendors don’t always credit researchers, or downplay the damage a vulnerability can cause. In fact, last month Microsoft and a prominent cybersecurity researcher got into a public spat about one such alleged incident.

An imbalance of power

Asked for comment about Askar’s most recent discovery, a Microsoft spokesperson said, “we value the critical role that the security research community plays in strengthening the security of our products, services, and the broader technology ecosystem. While independent researchers determine when and how to publish their findings, we remain committed to rapidly assessing reported issues, mobilizing the appropriate engineering and security response resources, and delivering mitigations, guidance, and protections as quickly as possible to help safeguard our customers.”

[Related content: Is the vulnerability disclosure process glitched?]

There is a balance between coordinating disclosure with a software vendor (CVD) and full disclosure, Askar told us. But, he added, there’s an imbalance of power. “A security researcher can pour countless hours into an issue, ensuring they develop a good proof of concept and provide all the steps to recreate the issue. With this, they hope to at least get an acknowledgement for their efforts, which they can use to further their security track record or, in the best case, a monetary bounty reward.”

However, he added, “If security vendors don’t adhere to their side of the bargain, public disclosure is one of the few options security researchers have (if they don’t want to sit on their vulnerabilities or sell them on the black market). It forces the vendor to acknowledge the security issue publicly and usually leads to a much faster resolution than any private communication would.”

This, said Enderle, creates problems for enterprises: “When vendor bureaucracy penalizes responsible disclosure, it alienates the security community and forces public zero-day drops, ultimately leaving enterprise customers holding the bag.”

Hole in GitHub’s browser-based VSCode editor could lead to stolen token

Thu, 04 Jun 2026 03:52:35 +0200

A vulnerability in GitHub’s browser-based VSCode editor could lead to the theft of a developer’s token under certain circumstances, says a researcher.

The issue, revealed this week in a blog by Ammar Askar, has apparently been already addressed by GitHub owner Microsoft. But it raises a questions about both DevOps security, and about the researcher’s allegation that, because Microsoft doesn’t treat bug discoveries seriously, he can justify giving it short notice before openly publishing vulnerabilities he finds.

First, the bug: Users of github.com may not realize it, but when they are on any repository, they can shift to github.dev and its browser-based version of VSCode just by changing the URL.

Why do this? Because the browser instance of VSCode is pretty powerful, Askar says in his blog. “You can view all the files in the repo (even if it’s a private one), you can send out pull requests, and even make commits.”

Rob Enderle, a IT consultant who heads the Enderle Group, agrees that jumping into VSCode this way is “an incredibly useful tactical tool for quick tasks. By just hitting the ‘.’ key in any GitHub repo, you instantly get a browser-based VS Code interface without having to clone gigabytes of data locally. It’s perfect for rapid PR reviews, quick documentation edits, or navigating code on the fly without breaking your workflow. Just keep in mind that it runs entirely in the browser sandbox; there’s no compute backend, no terminal, and no code execution.”

For any heavy lifting or actual compiling, he added, the developer will still need the raw compute of a local workstation, or a full cloud environment like Codespaces.

The problem, Askar says, is that this functionality is achieved by github.com POSTing over an OAuth token to github.dev that allows it to interact with GitHub on your behalf. “The token is not scoped to the particular repo you interacted with, meaning it has full access to every other repo that you have access to,” he wrote in the blog.

“The presence of this token, and the fact that this web app is running almost the entire brunt of VSCode’s million line Typescript codebase, makes it a great target for anyone looking into VSCode bugs,” he wrote.

The exploit

Askar said that a threat actor could install an extension in a repository using a Jupyter notebook, a web application for creating and sharing computational documents that has the ability to install a malicious local workspace extension while skipping the publisher trust check. In his proof of concept, Askar said that once his payload runs, the newly installed extension will grab the GitHub API token, run a query to get the private repos the developer has access to, and then print out the replies and the token.

This vulnerability also exists in the desktop version of VSCode, Askar said, though it’s harder to exploit, since a threat actor would need to convince the victim to clone their repo and open the notebook containing the webview script payload. “Of course,” he added, “if you [the hacker] had some other XSS [cross-site scripting attack] in a webview that you can get a victim to open, you get effectively full RCE [remote code execution] on their computer.”

In an email, he said this vulnerability was “about as serious as it gets. Any website on the internet could have redirected you to a github.dev link that could have provided an attacker a token to read and modify your code repos. If one could convince the maintainer of a popular software project to click a link, they could have made whatever modifications they wanted to their project.”

This means, said Enderle, “we have to start treating developer endpoints with strict, isolated, zero-trust parameters, because we clearly cannot rely on vendor complacency to protect us.”

This issue reinforces the point that you should never follow any links unless you know exactly where they will take you, added Dwayne McDaniel, principal developer advocate at GitGuardian.

Short notice

Here’s where things get complicated. Because of an unhappy experience when disclosing a previous VSCode vulnerability to Microsoft — the bug was fixed, but Askar wasn’t given credit — this time he only gave GitHub one hour notice that this new discovery was going to be published. Microsoft applied what Askar calls a “stopgap” fix by adding a confirmation when a developer opens notebooks in web VSCode, and by not allowing the trusted publisher requirement to be skipped by commands.

[Related content: When responsible disclosure becomes unpaid labor]

An ethical question

Askar’s short notice raises an ethical question: How far in advance should a responsible researcher give notice to a vendor about a vulnerability before publicly revealing it?

These days, most infosec pros agree that notice must be given, or else a threat actor can quickly exploit a hole. Not only that, but the researcher risks damage to their reputation if reasonable notice isn’t given. Experienced researchers often give vendors at least 30 days to create and distribute a patch.

For their part, vendors often create bug bounty programs, or partner with bug bounty programs, to reward researchers for their work. Unfortunately, some vendors don’t always credit researchers, or downplay the damage a vulnerability can cause. In fact, last month Microsoft and a prominent cybersecurity researcher got into a public spat about one such alleged incident.

An imbalance of power

Asked for comment about Askar’s most recent discovery, a Microsoft spokesperson said, “we value the critical role that the security research community plays in strengthening the security of our products, services, and the broader technology ecosystem. While independent researchers determine when and how to publish their findings, we remain committed to rapidly assessing reported issues, mobilizing the appropriate engineering and security response resources, and delivering mitigations, guidance, and protections as quickly as possible to help safeguard our customers.”

[Related content: Is the vulnerability disclosure process glitched?]

There is a balance between coordinating disclosure with a software vendor (CVD) and full disclosure, Askar told us. But, he added, there’s an imbalance of power. “A security researcher can pour countless hours into an issue, ensuring they develop a good proof of concept and provide all the steps to recreate the issue. With this, they hope to at least get an acknowledgement for their efforts, which they can use to further their security track record or, in the best case, a monetary bounty reward.”

However, he added, “If security vendors don’t adhere to their side of the bargain, public disclosure is one of the few options security researchers have (if they don’t want to sit on their vulnerabilities or sell them on the black market). It forces the vendor to acknowledge the security issue publicly and usually leads to a much faster resolution than any private communication would.”

This, said Enderle, creates problems for enterprises: “When vendor bureaucracy penalizes responsible disclosure, it alienates the security community and forces public zero-day drops, ultimately leaving enterprise customers holding the bag.”

This article originally appeared on InfoWorld.

CVE-2024-6684 | GST Electronics inohom Nova Panel N7 up to 1.9.9.6 authentication bypass

Thu, 04 Jun 2026 00:24:47 +0200
A vulnerability labeled as critical has been found in GST Electronics inohom Nova Panel N7 up to 1.9.9.6. Impacted is an unknown function. The manipulation results in authentication bypass using alternate channel. This vulnerability only affects products that are no longer supported by the maintainer. This vulnerability was named CVE-2024-6684. The attack may be performed from remote. There is no available exploit.

CVE-2024-1202 | XPodas Octopod prior 1.0 authentication bypass

Wed, 03 Jun 2026 20:06:25 +0200
A vulnerability was found in XPodas Octopod. It has been declared as very critical. This vulnerability affects unknown code. The manipulation results in authentication bypass by primary weakness. This vulnerability only affects products that are no longer supported by the maintainer. This vulnerability is identified as CVE-2024-1202. The attack can be executed remotely. There is not any exploit available. It is recommended to upgrade the affected component.

CVE-2026-49143 | browserstack browserstack-runner up to 0.9.5 HTTP /_log vm.runInNewContext code injection (GHSA-6vr3-7wcx-v5g5 / EUVD-2026-34029)

Wed, 03 Jun 2026 18:39:05 +0200
A vulnerability identified as critical has been detected in browserstack browserstack-runner up to 0.9.5. Affected by this vulnerability is the function vm.runInNewContext of the file /_log of the component HTTP Handler. The manipulation leads to code injection. This vulnerability only affects products that are no longer supported by the maintainer. This vulnerability is uniquely identified as CVE-2026-49143. The attack can only be initiated within the local network. No exploit exists.

[$] Open-source security is not a solo activity

Wed, 03 Jun 2026 17:10:19 +0200

Over time, many open-source maintainers face the same problem: they lack the time to do all of the work that their project needs, and no one else is stepping up to provide adequate help. Maintainers, though, are often reluctant to throw in the towel. The result is suboptimal all around; the maintainer is stressed out, project quality suffers, and users face security risks that they may not be fully aware of. At the 2026 Open Source Summit North America, Robin Bender Ginn spoke about this problem, when it might be time for maintainers to pass the torch, and the responsibilities of users.

CVE-2024-6921 | NAC Telecommunication Systems NACPremium up to 01082024 cleartext storage

Wed, 03 Jun 2026 16:39:22 +0200
A vulnerability was found in NAC Telecommunication Systems NACPremium up to 01082024 and classified as problematic. Impacted is an unknown function. The manipulation results in cleartext storage of sensitive information. This vulnerability only affects products that are no longer supported by the maintainer. This vulnerability is identified as CVE-2024-6921. The attack can be executed remotely. There is not any exploit available.

CVE-2024-6919 | NAC Telecommunication Systems NACPremium up to 01082024 sql injection

Wed, 03 Jun 2026 16:39:18 +0200
A vulnerability, which was classified as critical, was found in NAC Telecommunication Systems NACPremium up to 01082024. This vulnerability affects unknown code. Executing a manipulation can lead to sql injection. This vulnerability only affects products that are no longer supported by the maintainer. The identification of this vulnerability is CVE-2024-6919. The attack may be launched remotely. There is no exploit available.

CVE-2024-6920 | NAC Telecommunication Systems NACPremium up to 01082024 cross site scripting

Wed, 03 Jun 2026 16:39:17 +0200
A vulnerability has been found in NAC Telecommunication Systems NACPremium up to 01082024 and classified as problematic. This issue affects some unknown processing. The manipulation leads to cross site scripting. This vulnerability only affects products that are no longer supported by the maintainer. This vulnerability is referenced as CVE-2024-6920. Remote exploitation of the attack is possible. No exploit is available.

Tridgell: rsync and outrage

Wed, 03 Jun 2026 15:06:47 +0200

Andrew Tridgell has written a blog post responding to complaints that he has begun using LLM tools in his work maintaining rsync:

Like many developers of open source packages I've been hit by a flood of security reports lately in my role as the rsync maintainer. Many of those reports are AI generated (not all though, there are some notable ones with very careful and high quality manual analysis).

As this flood started to get more intense I realised I needed to raise the defences on rsync a lot — we needed much more thorough test suites, code coverage analysis, CI testing on a lot more platforms, deliberate and thorough scanning for possible security issues (so I find at least some of them before other people!) and the addition of a whole lot of defence-in-depth hardening techniques.

[...] Now to the future, because we're not done yet by a long shot. The security reports keep rolling in. I'm working on a bunch of CVEs right now. Luckily I've been joined by some other very good developers with great systems development skills and security knowledge. Some of these people came to my attention partly because of all the rage happening at the moment, so I get some rage storm clouds have silver linings. Watch out for some credits for some great new rsync developers in the next release.

[$] Caching for extended attributes

Tue, 02 Jun 2026 20:38:49 +0200
Extended attributes (xattrs) provide a way to attach key/value metadata to inodes—files, directories, and the like—in a filesystem. As with many Linux filesystems, the FUSE filesystem supports xattrs. In a filesystem-track session at the 2026 Linux Storage, Filesystem, Memory Management, and BPF Summit, FUSE maintainer Miklos Szeredi led a discussion about caching xattrs in kernel memory; he would like to create some common infrastructure that could be used by FUSE and shared with other filesystems.

CVE-2025-8732 | libxml2 up to 2.14.5 xmlcatalog xmlParseSGMLCatalog recursion (Issue 958 / EUVD-2025-24001)

Tue, 02 Jun 2026 19:09:58 +0200
A vulnerability classified as problematic has been found in libxml2 up to 2.14.5. The impacted element is the function xmlParseSGMLCatalog of the component xmlcatalog. Performing a manipulation results in uncontrolled recursion. This vulnerability is reported as CVE-2025-8732. The attack requires a local approach. Moreover, an exploit is present. The real existence of this vulnerability is still doubted at the moment. The code maintainer explains, that "[t]he issue can only be triggered with untrusted SGML catalogs and it makes absolutely no sense to use untrusted catalogs. I also doubt that anyone is still using SGML catalogs at all."

The Rust Programming Language Blog: Launching the Rust Foundation Maintainers Fund

Tue, 02 Jun 2026 19:09:27 +0200

If you want to financially support the development of Rust, please consider donating to the Rust Foundation Maintainers Fund.

A few months ago, the Rust Foundation announced the Rust Foundation Maintainers Fund (RFMF). Since then, the Rust Project has been closely cooperating with the Rust Foundation to determine how exactly this fund will be used to support Rust maintainers. This resulted in the acceptance of RFC #3931, which established the Funding team and the Maintainer in Residence program.

The primary goal of the Funding team is to ensure that maintainers who work on Rust and its toolchain will be properly supported. We will talk to Rust Project members to figure out their funding situation, meet Rust team leads to learn about their maintenance needs, approach companies to find opportunities for them to invest into Rust by supporting Rust maintainers, coordinate various funding efforts and ensure that the beneficial effects of funded maintenance are visibly promoted, with the help of the Content team.

Maintainer in Residence is a new program dedicated to financially supporting existing Rust Project maintainers¹. Each Maintainer in Residence will be funded to maintain one or more critical parts of Rust, such as the compiler, the standard library, Cargo, Clippy or one of many other projects that the Rust Project develops and maintains. The funded work will include activities such as performing large-scale refactorings, code reviews, unblocking new features, issue triaging, mentoring other contributors and more, and will be split between priorities guided by the teams they are supporting and priorities of their own choosing within the Project. Where applicable, Maintainers in Residence are also encouraged to propose, champion, and drive forward Rust Project Goals.

The goal of this program is to provide stable and long-term funding so that maintainers can focus on important work that ensures the long-term health of Rust. The funding team will select Maintainers in Residence based on funding availability and maintenance needs within the Rust Project, and help ensure that they are successful. We expect that this will usually be a (near) full-time position, but that will depend on the nature of the work and the area of maintenance.

This program extends our existing support for Rust maintainers, such as the program management program and the compiler-ops program. An important development is that we now have a centralized mechanism for gathering donations from both individuals and companies, and a dedicated team that will help direct those funds to specific maintainers. You can find more details about the funding team and the Maintainer in Residence program in the RFC.

We expect to hire the first Maintainer in Residence in the upcoming months and announce it on this blog, so stay tuned!

How to contribute funds

If you are an individual who wants to help Rust succeed and thrive, you can donate to the RFMF through GitHub Sponsors². Companies who would like to invest in better maintenance of Rust can also donate through GitHub Sponsors or they can contact the Rust Foundation directly.

The important thing is that all proceeds from this fund will be directly used to support Rust Project maintainers. We currently expect that to happen primarily through the Maintainer in Residence program, but it can also be done in the form of smaller-scale grants or other mechanisms, as determined by the Funding team. We will figure this out on the go, as this is also quite new for us.

We really appreciate each donation, however small, because with more money we can hire more maintainers to ensure that we can continue to develop Rust and that important improvements are not blocked on maintenance tasks. This is especially important at this time, where Rust is starting to get used more and more in the industry in various application areas, which increases the need for sustained maintenance. The importance of multiple funding sources is underscored by an unfortunate trend we currently observe, where key Rust maintainers are losing their funding for Rust work due to budget shifts. The Rust Foundation Maintainers Fund is designed to provide stable funding for Rust maintainers that is less dependent on sudden shifts in the job market and the IT industry.

As with most things, there is no one-size-fits-all solution, so there are multiple ways to support Rust financially. The RustNL Maintainers Team recently hired several Rust Project maintainers. Previously, we wrote about how you can support specific individuals working on Rust. And there are also Rust Project Goals in search of funding. We welcome all efforts that can help support Rust Project maintainers, who often do work that is near invisible and thankless, while at the same time incredibly important and necessary, on a volunteer basis.

Thank you for considering sponsoring the development and maintenance of Rust! You can find more information about funding Rust on our Funding page.

This program was inspired by the Developer in Residence concept used by the Python Software Foundation (PSF), with which we led several helpful discussions. Thank you, PSF! ↩

Note that the fact that GitHub Sponsors is currently enabled on the rustfoundation GitHub organization, and not the rust-lang organization, is an implementation detail that might change in the future. All donations raised on this Sponsors page will be routed to the Rust Foundation Maintainers Fund and will be spent on directly supporting Rust Project maintainers. ↩

CVE-2024-9477 | AirTies Air4443 up to 1.6.1.6 cross site scripting

Tue, 02 Jun 2026 13:38:50 +0200
A vulnerability described as problematic has been identified in AirTies Air4443 up to 1.6.1.6. This affects an unknown function. Executing a manipulation can lead to cross site scripting. This vulnerability only affects products that are no longer supported by the maintainer. This vulnerability is registered as CVE-2024-9477. It is possible to launch the attack remotely. No exploit is available.

CVE-2024-10035 | BG-TEK Informatics Security Technologies CoslatV3 up to 3.1069 code injection

Tue, 02 Jun 2026 13:08:46 +0200
A vulnerability has been found in BG-TEK Informatics Security Technologies CoslatV3 up to 3.1069 and classified as critical. Affected is an unknown function. This manipulation causes code injection. This vulnerability only affects products that are no longer supported by the maintainer. This vulnerability is registered as CVE-2024-10035. The attack needs to be launched locally. No exploit is available.

CVE-2024-12016 | CM Informatics CM News up to 6.0 sql injection

Tue, 02 Jun 2026 10:08:14 +0200
A vulnerability described as critical has been identified in CM Informatics CM News up to 6.0. Affected by this issue is some unknown functionality. Such manipulation leads to sql injection. This vulnerability only affects products that are no longer supported by the maintainer. This vulnerability is listed as CVE-2024-12016. The attack may be performed from remote. There is no available exploit.

Ombredanne: An AI agent ported our codebase from Python to Rust

Mon, 01 Jun 2026 23:24:24 +0200
Over on the AboutCode blog, lead maintainer Philippe Ombredanne writes about an agentic LLM system porting the ScanCode Toolkit to Rust. In the process, the LLM (or the people behind it) infringed the ScanCode trademark, stripped copyright and license notices, "and started an outreach campaign, without ever engaging the AboutCode community". Ironically, the toolkit is used to scan source code and binaries in order to figure out licensing and copyright information; it also reports on package dependencies, vulnerabilities, and more.
This is worth repeating: A comprehensive test suite, decent documentation, and curated datasets is what makes automated porting possible. It is also what makes a codebase easier to replicate without understanding it.
The agent's initial approach, using an existing Rust license-detection library, failed to match ScanCode's output quality. The agent then did what any translator would do when a loose paraphrase fails: it copied the original more closely. The final port reproduces ScanCode's core algorithms, code organization, and data-driven architecture in Rust, not because the agent understood them, but because it had enough training data and test feedback to converge on equivalent code.

Nick Fitzgerald: A Structure-Aware Fuzzing Experiment

Mon, 01 Jun 2026 19:24:02 +0200

Structure-aware fuzzing can better exercise the system under test (SUT) by crafting inputs in the format expected by the SUT, rather than throwing pseudorandom bytes against it. That is, it avoids “shallow” inputs that the SUT will reject early (for example, syntactically invalid source text when fuzzing a programming language’s compiler) and only produces inputs that go “deep” into the SUT (e.g. programs that type-check and exercise the mid-end optimizer and backend code generator). The Rust fuzzing ecosystem is largely built around cargo-fuzz and the libfuzzer-sys crate, which provides two methods for structure-aware fuzzing:

Generating structured inputs from scratch with the arbitrary crate

Mutating existing inputs from the fuzzer’s corpus in a structure-aware manner, thereby producing new structured inputs, via the fuzz_mutator! hook

While the two methods are not technically mutually exclusive, combining the two can be difficult and engineering resources are finite. So:

If we are only implementing one approach, is generation or mutation better?

To help answer this question, I implemented structure-aware generation and mutation of guaranteed-valid WebAssembly (Wasm) instruction sequences. This task is small enough to be easily understandable but large enough and real enough to (hopefully) be representative and applicable to other domains, or, at the very least, interesting.¹ To evaluate their effectiveness, I used Wasmtime as the SUT, libfuzzer-sys as the fuzzing engine driving everything, and then compared code coverage over time when using mutation-based fuzzing versus generation-based fuzzing.

Additionally, there are many ways we can generate pseudorandom WebAssembly instruction sequences. In this experiment, I’ve evaluated three methods:

Unconstrained instruction sequence generation followed by a fixup pass to ensure validity

Generating valid instructions in a forwards, bottom-up manner (from operands to operators)

Generating valid instructions in a backwards, top-down manner (from operators to operands)

In contrast, while there are surely many ways to mutate a given WebAssembly instruction sequence into a new, valid instruction sequence, I’ve only implemented one method: perform an arbitrary instruction insertion, deletion, or replacement, producing a new but probably-invalid instruction sequence, and then run the same fixup pass mentioned previously to ensure validity. This is the direct mutation-based equivalent of the first generation-based method.

Before continuing further, I want to disclose that I am the author of wasm-smith and mutatis, and a maintainer of Wasmtime, arbitrary, libfuzzer-sys, and cargo-fuzz. That is, while I am familiar with Wasm, fuzzing, fuzzing Wasm, and both the arbitrary and mutatis crates, I may also be propagating my own biases into these implementations.

Background

Generation-Based and Mutation-Based Fuzzing

A generation-based fuzzer uses a generator to create a pseudo-random test cases from scratch, feeds these into the system under test, and reports any failures to the user:

fn generation_based_fuzzing<T>( // A test-case generator. generator: impl Fn() -> T, // A function to run the system under test with a // generated test case, returning a result that // describes whether the run was successful or // not. run_system_under_test: impl Fn(&T) -> FuzzResult, ) { loop { // Generate an input. let input = generator(); // Run the input through the system under test. let result = run_system_under_test(&input); // If the system crashed, panicked, failed an // assertion, violated an invariant, or etc... // then report that to the user. if let Err(failure) = result { report_to_user(&input, failure); } } }

On the other hand, mutation-based fuzzers are given an initial corpus of inputs and create new inputs by mutating existing corpus members. They run each new input through the SUT, report failures the same as before, and if the new input was “interesting” (for example, exercised new code paths in the SUT that weren’t previously covered in any other input’s execution) then the new input is added into the corpus for use in future test iterations:

fn mutation_based_fuzzing<T>( // A corpus of test cases. corpus: &mut Corpus<T>, // A function to pseudo-randomly mutate an existing // input into a new input. mutate: impl Fn(&T) -> T, // A function to run an input in the system under // test, returning a result that describes whether // the run was successful or not. run_system_under_test: impl Fn(&T) -> FuzzResult, ) { loop { // Choose an old test case from the corpus. let old_input = corpus.choose_one(); // Pseudo-randomly mutate that old test case, // creating a new one. let input = mutate(old_input); // Run the input through the system under test. let result = run_system_under_test(&input); // If the system crashed, panicked, failed an // assertion, violated an invariant, or etc... // then report that to the user. if let Err(failure) = result { report_to_user(&input, failure); } // If the input was interesting, for example if // it executed previously-unknown code paths, // then add it into the corpus for use in a // future iteration. if result.input_was_interesting() { corpus.insert(input); } } }

The two approaches are not mutually exclusive and hybrid generation- and mutation-based fuzzers exist.

More resources:

Wikipedia’s “Fuzzing” article’s “Reuse of existing input seeds” section

The Fuzzing Book’s Mutation-Based Fuzzing chapter

Writing a Test Case Generator for a Programming Language

Structure-Aware Fuzzing

Structure-unaware fuzzing will generate pseudorandom byte sequences and pass them directly to the SUT. If the SUT expects some sort of structured input, e.g. the source text for a programming language, it is likely that these byte sequences are invalid and will be rejected early by the SUT’s frontend. For example, when fuzzing a compiler, the input is rejected as syntactically invalid by the parser or rejected as semantically invalid by the type checker. This can be useful when hardening a tokenizer, parser, or type checker, but is less useful when hunting for misoptimization in the mid-end or bad instruction encoding in the backend because the inputs are unlikely to make it that far through the compiler’s pipeline.

Structure-aware fuzzing will produce inputs that match the SUT’s expected input format. Returning to the compiler-fuzzing example, structure-aware fuzzing lets us generate valid programs for the compiler, so we can exercise more of the mid-end and backend, rather than just the frontend.

Structure-aware fuzzing is often generation-based: for example using grammar-based fuzzing to generate pseudorandom strings from a given language grammar or language-specific tools like csmith and wasm-smith that generate C and WebAssembly programs respectively. But structure-aware fuzzing can also be mutation-based: libFuzzer’s custom mutator example implements a structure-aware mutator for zlib-compressed strings, where the raw input is decompressed, the decompressed data is mutated, and then the mutated data is recompressed to provide the new raw input. The mutator is aware of the SUT’s zlib-compressed input structure.

More resources:

Wikipedia’s “Fuzzing” article’s “Aware of input structure” section

google/fuzzing on structure-aware fuzzing

The rust-fuzz book on structure-aware fuzzing

The arbitrary Crate

The arbitrary crate helps Rust developers write custom structure-aware generators for fuzzing. It provides building blocks and abstractions for translating a raw byte sequence (usually from a fuzzing engine) into a structured type, effectively interpreting the raw bytes as a “DNA string” or set of predetermined choices for its decision tree. The library also provides a derive(Arbitrary) macro to automatically implement its functionality for a given type.

Because arbitrary is effectively implemented by combining decision trees, it is extremely easy to create imbalanced trees and unintentionally bias the distribution of generated test cases.

The mutatis Crate

The mutatis crate is, at a high-level, performing the same role for authoring structure-aware mutators that arbitrary plays for generators. That is, it provides Rust developers with abstractions and combinators for creating custom structure-aware mutators. It also provides a derive(Mutate) macro to automatically implement its functionality for a given type.

mutatis is designed to resist bias via a two-phase design: first, it enumerates all of the candidate mutations that could be applied to a test case, and only afterwards chooses a particular random mutation from the candidate set to actually apply.

WebAssembly

WebAssembly is a virtual instruction set designed to be safe, portable, and fast. It is a stack machine where an instruction’s operands are popped off a stack during execution and results pushed. It has sandboxed linear memories, global variables, and local variables (the latter two effectively being two kinds of virtual registers). The following instruction sequence computes a * 3 and stores the result into memory at address p:

;; [] local.get $p ;; [p] local.get $a ;; [p, a] i32.const 3 ;; [p, a, 3] i32.mul ;; [p, a*3] i32.store ;; []

Generator and Mutator Implementation

The range of all three generators and the mutator is the same universe of WebAssembly programs. They are all implemented on top of the same Module and Inst types, and, given enough time, none is capable of producing an instruction sequence that another cannot. This helps ensure that our comparison is apples-to-apples. However, due to their different implementation techniques, they do produce different distributions of WebAssembly programs within that universe, and produce test cases at different speeds from one another, which ultimately affects how efficiently they exercise the SUT.

All of the generators are built on top of the arbitrary crate. The mutator is built on top of the mutatis crate.

The Module type is our structured fuzzing input. It describes a WebAssembly module containing a variable number of linear memories, a variable number and type of globals, and one function with a variable number and type of parameters and results and a variable instruction sequence:

/// A WebAssembly module of the shape: /// /// (module /// (memory ...) /// (memory ...) /// ... /// /// (global ...) /// (global ...) /// ... /// /// (func (export "run") (param ...) (result ...) /// ... /// ) /// ) pub struct Module { num_memories: u32, globals: Vec<Global>, param_types: Vec<ValType>, result_types: Vec<ValType>, instructions: Vec<Inst>, }

The Inst type is an enum of all the WebAssembly instructions the implementations support, which is all of the integer, float, SIMD, memory, local, and global instructions. Control-flow, threading, table, and GC instructions are not supported. Here is a subset of Inst’s definition:

/// A WebAssembly instruction. pub enum Inst { Drop, LocalGet(u32), GlobalGet(u32), // ... I32Const(i32), I32Add, I32Sub, I32Mul, // ... I64Const(i64), I64Add, I64Sub, I64Mul, // ... F32Const(f32), F32Add, F32Sub, F32Mul, // ... F64Const(f64), F64Add, F64Sub, F64Mul, // ... I32WrapI64, I64ExtendI32S, I64ExtendI32U, // ... V128Const(i128), I8x16Add, I8x16Sub, // ... I32Load(u32), I64Load(u32), // ... I32Store(u32), I64Store(u32), // ... MemorySize(u32), MemoryGrow(u32), }

There is an Inst::operand_types method that returns the types that the instruction pops from the stack, and an Inst::result_type method that returns the type of the value that the instruction pushes onto the stack, if any. Finally, the Module::to_wasm_binary method encodes the module into WebAssembly’s binary format, so it can be fed into Wasmtime. These methods are used, directly or indirectly, in every generator and mutator implementation.

arb

The arb generator leverages derive(arbitrary::Arbitrary) on our structured input types to generate a pseudorandom instance of Module, unconstrained by validity. The module’s instruction sequence is almost certainly not valid at this point: it likely is missing operands for instructions, producing more results than the function’s signature describes, producing results of types that don’t match the function signature, accessing globals and locals that don’t exist, etc… Having produced an instance of Module, it next calls the Module::fixup method to mutate the Module so that it is valid.

The fixup method works by abstractly interpreting the instruction sequence to track the types of each value on the stack at every program point. Whenever an instruction’s operand types don’t match the types on top of the stack, it generates dummy values of the correct type. When the instructions produce more values than the function’s signature proscribes, it emits drop instructions.

impl Module { pub fn fixup(&mut self, mut make_value: impl FnMut() -> i64) { // ... // The fixed-up instructions. let mut fixed = Vec::with_capacity( self.instructions.len(), ); // The types on the stack at any given program // point. Similar to the Wasm spec's appendix's // validation algorithm. let mut stack: Vec<ValType> = Vec::new(); for inst in mem::take(&mut self.instructions) { // Special-case `drop` because it is // polymorphic. if matches!(inst, Inst::Drop) { if stack.is_empty() { fixed.push( ValType::I32.make_const(make_value()), ); } else { stack.pop(); } fixed.push(inst); continue; } // First clamp entity indices to valid // ranges. let Some(inst) = self.fixup_inst_immediates( &mut make_value, has_mutable_global, inst, ) else { continue }; // Then make sure that the stack has // operands of the correct types for this // instruction. self.fixup_stack( &mut make_value, &mut fixed, &mut stack, &inst, ); // Finally, apply the effects to the stack. let len_operands = inst.operand_types( &self.globals, ).len(); stack.truncate(stack.len() - len_operands); stack.extend(inst.result_type( &self.param_types, &self.globals, )); fixed.push(inst); } // ... self.instructions = fixed; } fn fixup_stack( &mut self, mut make_value: impl FnMut() -> i64, fixed: &mut Vec<Inst>, stack: &mut Vec<ValType>, inst: &Inst, ) { let needed = inst.operand_types(&self.globals); let n = needed.len(); if stack.len() >= n { if (0..n).all(|i| { stack[stack.len() - n + i] == needed[i] }) { // All needed operands are on the stack. return; } } else { if stack.iter().enumerate().all(|(i, ty)| { *ty == needed[i] }) { // A prefix of needed operands are on the // stack; make constants for the tail that // are missing. for ty in &needed[stack.len()..] { fixed.push(ty.make_const(make_value())); stack.push(*ty); } return; } } // Otherwise, just make constants for all the // needed operands. for ty in needed { fixed.push(ty.make_const(make_value())); stack.push(*ty); } } // ... }

The fixup method also makes sure that for all instructions that have an immediate referencing some entity, the referenced entity is valid. For example, for a local.get $l instruction, it ensures that local $l actually exists or else rewrites the local to one that does exist.

impl Module { // ... fn fixup_inst_immediates( &mut self, mut make_value: impl FnMut() -> i64, has_mutable_global: bool, mut inst: Inst, ) -> Option<Inst> { match &mut inst { Inst::LocalGet(l) => *l %= self.param_types.len() as u32, // ... Inst::I32Load(m) | Inst::I64Load(m) | Inst::F32Load(m) | Inst::F64Load(m) | Inst::V128Load(m) => { if self.num_memories == 0 { return None; } *m %= self.num_memories; } // ... _ => {} } Some(inst) } }

After calling fixup, the arb generator invokes Module::to_wasm_binary to get the encoded Wasm program.

bottom_up

The bottom_up generator also uses abstract interpretation to track the types of values on the stack. It generates instructions in forwards order, from operands to operators. It begins with an empty stack, filters candidate instructions down to just those that would be valid given the types currently on the stack, randomly chooses one, updates the stack types accordingly, and repeats the process. This is the same approach that wasm-smith uses. After generating instructions this way, it then makes sure that the final types on the stack match the function signature’s results, similar to the end of fixup.

impl Module { pub fn bottom_up(u: &mut Unstructured<'_>) -> Result<Self> { // ... let max_insts = u.int_in_range(1..=MAX_INSTS)?; let mut instructions = Vec::new(); let mut stack: Vec<ValType> = Vec::new(); for _ in 0..max_insts { if stack == result_types && u.ratio(3, 4)? { break; } // Choose a random instruction whose operand // types match those currently on the stack. let inst = choose_inst_bottom_up( u, &stack, &param_types, &globals, num_memories, )?; // Apply this instruction's effects to the // stack. apply_inst( &inst, &mut stack, &param_types, &globals, ); instructions.push(inst); } // ... Ok(Module { param_types, result_types, globals, num_memories, instructions, }) } } fn choose_inst_bottom_up( u: &mut Unstructured<'_>, stack: &[ValType], param_types: &[ValType], globals: &[Global], num_memories: u32, ) -> Result<Inst> { // Build up all the valid candidate instructions. let mut candidates: Vec<Inst> = Vec::new(); // Producers are always okay: [] -> [t] candidates.push(Inst::I32Const(0)); candidates.push(Inst::I64Const(0)); candidates.push(Inst::F32Const(0.0)); candidates.push(Inst::F64Const(0.0)); candidates.push(Inst::V128Const(0)); if !param_types.is_empty() { candidates.push(Inst::LocalGet(0)); } // ... let top = stack.last().copied(); let second = stack.get(stack.len() - 2).copied(); // Drop needs 1 operand of any type: [t] -> [] if top.is_some() { candidates.push(Inst::Drop); } // i32 unary: [i32] -> [...] if top == Some(I32) { candidates.push(Inst::I32Clz); candidates.push(Inst::I32Ctz); candidates.push(Inst::I32Popcnt); // ... } // i64 unary: [i64] -> [...] if top == Some(I64) { candidates.push(Inst::I64Clz); candidates.push(Inst::I64Ctz); candidates.push(Inst::I64Popcnt); // ... } // ... // i32 binary: [i32 i32] -> [...] if top == Some(I32) && second == Some(I32) { candidates.push(Inst::I32Add); candidates.push(Inst::I32Sub); candidates.push(Inst::I32Mul); // ... } // i64 binary: [i64 i64] -> [...] if top == Some(I64) && second == Some(I64) { candidates.push(Inst::I64Add); candidates.push(Inst::I64Sub); candidates.push(Inst::I64Mul); // ... } // ... // Choose a random instruction from the // candidates. let mut inst = *u.choose(&candidates)?; // If the instruction has immediates, generate // them here, as they were hard-coded during // candidate selection. match &mut inst { Inst::I32Const(v) => *v = u.arbitrary()?, Inst::I64Const(v) => *v = u.arbitrary()?, // ... Inst::GlobalGet(g) => { *g = u.int_in_range(0..=(globals.len() as u32 - 1))?; } // ... Inst::I32Load(m) | Inst::I64Load(m) | Inst::F32Load(m) | Inst::F64Load(m) | Inst::V128Load(m) | Inst::I32Store(m) | Inst::I64Store(m) | Inst::F32Store(m) | Inst::F64Store(m) | Inst::V128Store(m) | Inst::MemorySize(m) | Inst::MemoryGrow(m) => { *m = u.int_in_range(0..=(num_memories - 1))?; } _ => {} } Ok(inst) }

After constructing a Module via bottom_up, we don’t need to call fixup because the module is already valid by construction, so all that’s left is invoking Module::to_wasm_binary to get the encoded Wasm program.

top_down

The top_down generator is very similar to bottom_up, but instead of generating instructions forwards, from operands to operators, it generates them backwards, from operators to operands. Instead of maintaining a stack of the types of values generated thus far by the instruction sequence prefix, it maintains a stack of the types of values expected by the instruction sequence suffix. This is the approach that rgfuzz by Park, Kim, and Yun takes.²

impl Module { pub fn top_down( u: &mut Unstructured<'_>, ) -> Result<Self> { // ... let max_insts = u.int_in_range(1..=MAX_INSTS)?; let mut instructions = Vec::new(); let mut needed = result_types.clone(); for _ in 0..max_insts { if needed.is_empty() && u.ratio(3, 4)? { break; } // Choose a random instruction in a // top-down manner. let inst = choose_inst_top_down( u, needed.last().copied(), &param_types, &globals, num_memories, )?; // Pop the result type from `needed`, if // any, as it's been satisfied. let ty = inst.result_type( &param_types, &globals, ); if ty == needed.last().copied() { needed.pop(); } // Add operand type demands. match &inst { Inst::Drop => { // `drop` is polymorphic; choose // a random type. needed.push(u.arbitrary()?); } Inst::GlobalSet(g) => { needed.push(globals[*g as usize].ty); } _ => { needed.extend_from_slice( inst.operand_types(&globals), ); } } instructions.push(inst); } // Fill remaining needed types with // constants. for ty in needed.iter().rev() { instructions.push( ty.make_const(u.arbitrary()?), ); } // Instructions were generated backwards, so // reverse. instructions.reverse(); Ok(Module { param_types, result_types, globals, num_memories, instructions: prefix, }) } } fn choose_inst_top_down( u: &mut Unstructured<'_>, target_ty: Option<ValType>, param_types: &[ValType], globals: &[Global], num_memories: u32, ) -> Result<Inst> { let mut candidates: Vec<Inst> = Vec::new(); match target_ty { Some(I32) => { candidates.push(Inst::I32Const(0)); candidates.push(Inst::I32Add); candidates.push(Inst::I32Sub); candidates.push(Inst::I32Mul); // ... } Some(I64) => { candidates.push(Inst::I64Const(0)); candidates.push(Inst::I64Add); candidates.push(Inst::I64Sub); candidates.push(Inst::I64Mul); // ... } Some(F32) => { candidates.push(Inst::F32Const(0.0)); candidates.push(Inst::F32Add); candidates.push(Inst::F32Sub); candidates.push(Inst::F32Mul); // ... } // ... None => { // Nothing needed. `drop`, `global.set`, and // stores add demand. candidates.push(Inst::Drop); if globals.iter().any(|g| g.mutable) { candidates.push(Inst::GlobalSet(0)); } if num_memories > 0 { candidates.push(Inst::I32Store(0)); // ... } } } let mut inst = *u.choose(&candidates)?; // If the instruction has immediates, generate // them here, as they were hard-coded during // candidate selection. Same as `bottom_up`. match &mut inst { // ... } Ok(inst) }

Similar to bottom_up, after we’ve constructed a Module via top_down, we don’t need to call fixup because the module is already valid by construction. All that’s left is invoking Module::to_wasm_binary to get the encoded Wasm program.

mutate

mutate is, as the name implies, a mutator rather than a generator. It is the direct equivalent of the arb generator, but for mutation: it uses derive(mutatis::Mutate) on Module and Inst to automatically generate custom mutators for these types, rather than authoring them by hand. After producing a new Module by mutating an old Module, that new Module probably represents an invalid Wasm program, in the same way that derive(arbitrary::Arbitrary) produces Modules that are probably invalid. And mutate also uses the same approach that arb does to resolve this problem: the fixup method.

But first, a mutator-specific wrinkle is that fuzz_mutator! gives us a mutable byte slice to mutate, not a Module. We address this gap by deriving the serde crate’s Serialize and Deserialize traits on Module and Inst, deserializing a Module from the mutable byte slice, mutating that deserialized Module with mutatis, and then reserializing it back into the mutable byte slice. We use the postcard crate here, but could just as easily use bincode, JSON, or protobuf.

use libfuzzer_sys::{fuzz_mutator, fuzz_target, fuzzer_mutate}; fuzz_mutator!(| data: &mut [u8], size: usize, max_size: usize, seed: u32, | { // With probability of about 1/8, use default // mutator. if seed.count_ones() % 8 == 0 { return fuzzer_mutate(data, size, max_size); } // Try to decode using postcard; fallback to // default input on failure. let mut module: Module = postcard::from_bytes(&data[..size]) .ok() .unwrap_or_default(); // Mutate with `mutatis`. let mut session = mutatis::Session::new() .seed(seed.into()) .shrink(max_size < size); if session.mutate(&mut module).is_ok() { if let Ok(encoded) = postcard::to_slice( &module, data, ) { return encoded.len(); } } // Fallback to the default libfuzzer mutator if // serialization or mutation fails because, for // example, `data` doesn't have enough capacity. fuzzer_mutate(data, size, max_size) });

Finally, the fuzz target itself deserializes the Module from the raw bytes, calls fixup, encodes it to a Wasm binary via Module::to_wasm_binary, and then passes that into Wasmtime.

fuzz_target!(|data: &[u8]| { let Ok(mut module) = postcard::from_bytes::<Module>(data) else { return; }; module.fixup(|| 0); let wasm = module.to_wasm_binary(); // ... });

Benchmarking

Methodology

We pair each of our generators and mutator with libfuzzer-sys and feed the resulting test cases into Wasmtime. All fuzzers start with an empty corpus.

The most important metric for a fuzzer is its bug-finding ability, but that can be difficult to measure directly. For example, Wasmtime is actively fuzzed 24/7 with more-complete fuzzers than those implemented here, so, as expected, I have not found any bugs via these benchmarks. Therefore, instead of reporting a found-bugs count, the benchmark harness reports two alternative metrics:

Coverage over time: Coverage is the cumulative code paths exercised by the fuzzer. A fuzzer cannot find bugs in code paths it does not cover. This is the most important metric reported.

Executions over time: An execution is one iteration of the fuzzing loop. This is basically measuring how fast the fuzzer can produce test cases. All else being equal, more executions is better, but all else is rarely equal. It is easy to generate poor test cases very quickly: just return an empty sequence of Wasm instructions every time. Unfortunately, that exclusively leads to useless executions. Therefore, this metric is really only useful when comparing two implementations of the same algorithm, and I’ve omitted its results in the next section.

Additionally, I report results for both 24 hours of fuzzing and 5 minutes of fuzzing. The expected behavior of long-term fuzzing, e.g. 24/7 fuzzing in OSS-Fuzz, can be extrapolated from the 24-hour results. The 5-minute results show the expected behavior of short-term fuzzing, e.g. when using mutatis::check or arbtest.

Discussion of short-term fuzzing is somewhat rare, so I feel its motivation deserves explanation. I find short-term fuzzing useful in the following scenarios, for example:

Running a quick fuzzing session locally, to catch bugs that avoid detection in the traditional unit- and integration-test suites, before opening a pull request.

Running some quick fuzzing in CI before allowing a pull request to merge, for similar reasons.

That is, short-term fuzzing is useful for the same reasons and in the same scenarios as property-based testing.³

As recommended in Evaluating Fuzz Testing by Klees, Ruef, Cooper, Wei, and Hicks and adopted in Fuzz Bench: An Open Fuzzer Benchmarking Platform and Service by Metzman, Szekeres, Simon, Sprabery, and Arya, the benchmark harness tests the statistical significance of its results with a Mann-Whitney U-test. The harness performs 20 trials per fuzzer, the same number of trials as Fuzz Bench.

Results

24 Hours of Fuzzing

arb has 1.00 ± 0.00 times more coverage than bottom_up (p = 0.01)

mutate has 1.01 ± 0.00 times more coverage than arb (p = 0.00)

top_down has 1.00 ± 0.00 times more coverage than arb (p = 0.00)

mutate has 1.02 ± 0.00 times more coverage than bottom_up (p = 0.00)

top_down has 1.01 ± 0.00 times more coverage than bottom_up (p = 0.00)

mutate has 1.01 ± 0.00 times more coverage than top_down (p = 0.00)

5 Minutes of Fuzzing

bottom_up has 1.01 ± 0.01 times more coverage than arb (p = 0.04)

mutate has 1.47 ± 0.02 times more coverage than arb (p = 0.00)

top_down has 1.06 ± 0.02 times more coverage than arb (p = 0.00)

mutate has 1.45 ± 0.01 times more coverage than bottom_up (p = 0.00)

top_down has 1.05 ± 0.02 times more coverage than bottom_up (p = 0.00)

mutate has 1.38 ± 0.02 times more coverage than top_down (p = 0.00)

Conclusion

The mutate fuzzer performs best. It vastly outperforms all the others at 5 minutes of fuzzing (36-49% more coverage), and while the rest narrow that gap after 24 hours of fuzzing, mutate maintains its lead (1-2% more coverage).

The comparison between arb and mutate is as apples-to-apples of a comparison as it gets between idiomatic test-case generation and mutation in Rust: derive(Arbitrary) and derive(Mutate). They use the same fixup method to ensure that the resulting Wasm instructions are valid. The fuzzer built with mutatis and test-case mutation provides better coverage over time than the fuzzer built with arbitrary and test-case generation. When writing structure-aware fuzzers, I used to reach for arbitrary; in the future, I will reach for mutatis instead.

The top_down fuzzer performs second-best, and is best of the generation-based fuzzers. This aligns with results from the rgfuzz paper, which found that top-down Wasm instruction generation resulted in better instruction diversity than bottom-up generation. This result is intuitive, they point out, because Wasm instructions tend to have more operands than results, which means that more candidates are filtered out from consideration when generating instructions in forward order from operands to results (bottom-up) than when generating them in backward order from results to operands (top-down).

Subjectively, none of the approaches feel significantly more-complicated nor easier to implement than the others. All approaches require a stack of types, representing the generated Wasm’s operand stack, at some point in their implementation. Some require it during instruction generation (top_down and bottom_up) while others require it during fixup (mutate and arb). Adding support for new Wasm instructions is roughly the same in all of them: add a new variant to enum Inst and define its operand and result types. top_down and bottom_up additionally require adding a line for the new instruction in their choose_inst_{top_down,bottom_up} functions, but this could be avoided with some targeted macro_rules! sugar.

The fixup method fixes instructions in a forwards order; as future work, it would be interesting to implement a backwards_fixup method that fixes instructions in a backwards order and see if mutate and backwards_fixup outperforms the current mutate and forwards fixup the same way that backwards generation (top_down) outperforms forwards generation (bottom_up).

fixup makes an attempt to reuse stack operands when it can, rather than synthesize dummy constants or drop already-computed values, but the attempt is somewhat half-hearted. Dropping operands introduces dead code, which is not very interesting for exercising deep into the compiler pipeline. Dummy constants are not that interesting either. Therefore, another potential line of follow-up work would be to investigate ways to maximize operand reuse and minimize drops and dummy constants inserted while ensuring validity. That could include storing values to memory or globals instead of droping them when possible. It could even include liberating ourselves from the stack-focused paradigm we’ve had thus far.

WebAssembly is a stack-based language and so it is natural that our approaches have focused on producing stack-y code. But, in practice, optimizing WebAssembly compilers like Wasmtime’s use a static single-assignment intermediate representation, and erase the operand stack early in their compilation pipelines. Therefore, from these compilers’ point of view, the following two WebAssembly snippets are identical:

;; `x = a + (b * c)` in a "stack-y" encoding and ;; without temporary locals. local.get $a local.get $b local.get $c i32.mul i32.add local.set $x ;; `x = a + (b * c)` in a "non-stack-y" encoding ;; that uses temporary locals for every operation. ;; ;; Equivalent of ;; ;; temp0 = b * c ;; temp1 = a + temp0 ;; x = temp1 local.get $b local.get $c i32.mul local.set $temp0 local.get $a local.get $temp0 i32.add local.set $temp1 local.get $temp1 local.set $x

Producing code that uses many temporaries in this manner might be easier than code that doesn’t, but, more importantly, it may enable better reuse of already-computed subexpressions, emit less dead code, and ultimately produce more interesting data-flow graphs that better exercise the deep innards of the compiler.

A final vein of interesting follow-up work to mine would be comparing arbitrary-based generators and mutatis-based mutators for structured inputs that are not programming languages and when the SUT we are fuzzing is not a compiler. Do we see these same results when, for example, producing PNG images to fuzz an image-transformation library?

Here is the source code for this experiment, including the three generators, one mutator, raw benchmark data, and benchmarking harness. The README includes instructions on running the benchmarks yourself.

WebAssembly’s stack-based instructions encode an expression tree — local.get $a; local.get $b; local.get $c; i32.add; i32.mul is isomorphic to a * (b + c) — so the experiment should be relevant and applicable to any other generator or mutator for a programming language with expressions, even if it might not appear so at first glance. ↩

Ignoring its rule-guided bit, which is orthogonal and could be applied to bottom_up as well. ↩

Structure-aware fuzzing and property-based testing are basically the same: convergent evolution from different communities. ↩

AI’s brave new world of technical debt

Mon, 01 Jun 2026 11:18:56 +0200

Mitchell Hashimoto wants you to stop updating your dependencies, which, from a historical context, is certifiably insane. In fact, in the wake of Mythos and the potential to make zero-day exploits common, it still may sound insane. Yet after the spring npm just had, Hashimoto’s counsel may actually sound less like heresy and more like control.

His rule? Fork your dependencies, trim them to what you actually use, and don’t update unless something breaks for your users. In Hashimoto’s view, you don’t update just because GitHub’s Dependabot opened a pull request or even because there’s a newer (presumably more secure) version. If you do update, the work of understanding every relevant commit in the transitive tree is yours, not the maintainer’s.

In an industry trained to equate “latest” with “secure,” this sounds reckless, until you look at what happened this spring. In two of the year’s worst npm attacks, many of the people most exposed were the ones pulling fresh versions. When the axios HTTP client library was compromised, attackers pushed two poisoned releases that dropped a remote-access Trojan on every machine that ran a fresh install during a roughly three-hour window. If you were pinned to a clean version and didn’t reinstall, you slept through it. Kudos to you. Weeks later, on the heels of a poisoned node-ipc release, the Mini Shai-Hulud worm self-propagated through TanStack and on to Mistral, UiPath, and a long tail of packages downloaded millions of times a week.

How do you defend against that?

Maybe by doing nothing. After all, the single most effective defense against Mini Shai-Hulud wasn’t a scanner or a signature. It was a cooldown. StepSecurity held newly published versions for a configurable window, around 10 days, before serving them to anyone. Customers on the cooldown kept getting the last known-good release and were never exposed, while the rest of the world found out the hard way.

In other words, the defense that worked was the unfashionable (and historically foolish) one: Don’t take the new version just because it’s new. Ironically, the industry’s answer to AI development seems to be to add more dependencies. What could go wrong?

The dependency tree escaped the package manager

For decades we’ve outsourced undifferentiated work to libraries, and mostly that’s good. After all, no one wants every team to hand-roll Transport Layer Security, date parsing, logging, etc., except perhaps the sort of person who compiles Gentoo for fun. (We know who you are!) Open source works because we specialize and share.

Sharing means we also borrow each other’s package managers, maintainer accounts, CI/CD pipelines, release scripts, etc. The miracle of modern software is that a small team can build something world-class out of a thousand components it didn’t write. That’s also the risk.

AI compounds this risk because the dependency tree is no longer confined to code.

A coding agent doesn’t just import packages: It also reads repo instructions, follows system prompts, picks tools, talks to Model Context Protocol (MCP) servers, and runs shell commands. Each capability is another dependency on behavior that lives outside the model. Some of this is useful, of course, but all of it is surface area, open to attack.

Consider that in a study of 117,062 dependency changes across seven ecosystems, researchers at Purdue found that AI agents selected known-vulnerable package versions more often than humans, 2.46% of the time versus 1.64%. The agents’ bad picks were also harder to undo: 36.8% required a major-version upgrade to remediate, against 12.9% for humans. At the aggregate level, agent-driven dependency work produced a net increase of 98 vulnerabilities while human-authored work produced a net reduction of 1,316. Agents also invent dependencies that don’t exist, which become an attack surface the moment someone registers the hallucinated name, as my InfoWorld colleague Lucian Constantin has covered.

Don’t take this as proof that humans always win. After all, developers have been making a mess of dependency graphs well before chatbots learned to obsequiously apologize. But letting agents “helpfully” add and update dependencies without guardrails is asking for a familiar problem at lightning-fast speed.

The MCP layer is its own version of the same trap. Microsoft has documented tool poisoning, in which malicious instructions hide inside the tool metadata a model reads to decide what to call. In its own red-team work, Microsoft found that relying on the model to follow safety instructions produced policy violations more than 25% of the time and concluded that instruction-following alone shouldn’t be treated as a security boundary. OWASP said it more plainly: A tool response goes straight into the model’s context with no equivalent of the review a tool description gets at connect time, and a prompt restriction like “don’t read files outside /tmp” is enforced by the model’s goodwill, not by access control.

That’s bad. Are prompts even worse?

Sean Goedecke recently argued that prompts also introduce technical debt and decay silently. A prompt that worked against one model behaves differently against the next. Pile enough of them together—the AGENTS.md and CLAUDE.md files, the skills, the rules, the tool descriptions—and you’ve quietly built an alternate control plane for how your software gets written. Most teams never test it, review it, or prune it, leaving your agents to make worse decisions while sounding perfectly reasonable.

‘Latest’ is not the same as safe

The extreme version of Hashimoto’s rules won’t fix this, and frankly, they won’t work for most teams. Most enterprises don’t have the staff, the patience, or the judgment for it. But strip away that extreme version and the discipline underneath is exactly right: Every dependency should have a reason to exist, and every update should have a reason to land.

This cuts against the grain of modern development, where adding a package feels cheaper than thinking. It cuts even harder against how agents work. Agents are very good at finding a library, importing it, and moving on. They optimize for the fastest path to a passing test, not for the long-term health of your dependency graph. This is the same gap I keep coming back to with evals: AI doesn’t eliminate engineering discipline; it raises the price of skipping it. The model can make the change faster. It can’t reliably tell you whether the change belongs in your system. That judgment is still yours.

Latent bugs won’t stay latent

Still, there’s a problem with Hashimoto’s approach, even the non-extreme version. Hashimoto’s bet assumes the undiscovered flaw in your frozen dependency stays undiscovered. For most of software history that was a safe assumption, because finding a deep logic bug in mature code was slow, expensive, human work. With AI that assumption no longer holds true.

In April, Anthropic’s Claude Mythos Preview autonomously found and built working exploits for a 16-year-old bug in FFmpeg and a 17-year-old root-access flaw in FreeBSD’s NFS server for under $20,000 across about a thousand runs. A month later, Google’s threat researchers flagged the first AI-developed zero-day seen in the wild, a semantic logic flaw of exactly the sort traditional scanners miss.

These old dependencies felt safe, but now a hacker can inexpensively rent the discovery of chinks in the armor.

This doesn’t refute Hashimoto, but it does require a refinement of his rules. Trimming a dependency to just your use case yields better control, because every function you didn’t import can’t be turned into a zero-day against you. Forking lets you patch on your own time instead of waiting on an upstream maintainer. Importantly, the same models scoring your code for the attackers can (and must) score it for you first.

The rule was never really not to update. It’s instead to know your surface, keep it small, and keep scoring it, because now everyone else is.

Fewer things, better understood

Yes, this changes the game. The best AI engineering teams won’t be the ones that wire agents into everything, sexy though that sounds. No, smart engineers will know precisely what they’ve wired in, why it’s there, and what happens when it changes.

That doesn’t mean banning MCP servers, agent tools, or third-party packages. That would be dumb. Rather it means treating all of them as production dependencies, because that’s what they are. If an MCP server can read email, query customer data, or execute code, it deserves the scrutiny of any other privileged integration. If a prompt file shapes how an agent edits your codebase, it belongs in version control, gets reviewed, and gets deleted when it stops being useful. This is where Goedecke’s advice and the governance instinct meet: Goedecke would keep that configuration layer as thin as he could, on the logic that the cheapest debt is the prompt you never wrote. The governance crowd would version, review, and gate whatever survives.

This isn’t really new. The history of this industry is littered with technologies that looked liberating until they became operational burdens, and the way to deal with them is usually the same. Microservices were going to free us from the monolith until many teams discovered they’d traded one big problem for 200 small ones connected by unreliable networks. Kubernetes was going to standardize infrastructure until companies realized they’d imported a distributed-systems project into every team.

Agents are following the same pattern, only faster. They make work easier by adding layers of delegation. Those layers become dependencies, and those dependencies become risk. That’s not an argument to stop, but it is an argument to be more thoughtful.

9 Naming-Praktiken zum Abgewöhnen

Mon, 01 Jun 2026 06:07:15 +0200

Geht’s um Naming, sollten Sie als Dev am besten so agieren, als würde Ihr Code von einem Psychopathen gewartet – der ganz genau weiß, wo Sie wohnen.
Master1305 | shutterstock.com

Ein betagter, aber immer noch beliebter Witz in Programmiererkreisen:

Es gibt zwei schwierige Dinge bei der Programmierarbeit: Cache Invalidation, Naming und Off-by-One-Fehler.

Während Erstgenanntes tatsächlich komplex ist und Letztgenanntes die Pointe darstellt, wirft die Einordnung von Naming Fragen auf. Denn Dinge in der Softwareentwicklung zu benennen, ist eigentlich simpel. Zumindest sollte es das sein. Leider legen jedoch nicht wenige Developer aus Gründen eine gewisse Aversion an den Tag, wenn es um Naming geht – und machen sich (und anderen) damit das Leben unnötig schwer. Schließlich können sinnvolle Benennungen nicht nur die kognitive Belastung bei der Codepflege erheblich reduzieren. Sie tragen auch dazu bei, Fehler zu vermeiden und Bugs zu verhindern.

In diesem Artikel beleuchten wir neun ausgesprochen schlechte Naming-Angewohnheiten, die Entwickler dringend abstellen sollten. Und geben einige Tipps, wie es besser geht.

1. Wissen voraussetzen

Wissen vorauszusetzen, ist in vielen Fällen der erste Schritt in den Naming-Untergang. Sie wissen vielleicht mit Sicherheit, dass EmpNo für „Employee Number“ steht und es sich um die unique ID in der Datenbank handelt. Ein neuer Dev hält es hingegen für etwas anderes, das nichts mit den Werten in der DB zu tun hat.

Wieso also nicht einfach die Dinge eindeutig beim Namen nennen? Zum Beispiel in Form von EmployeeUniqueIDInDatabase. Das ist zugegeben etwas lang, dafür sind folgenreiche Verwechslungen aber dank des klaren, deskriptiven Namings ausgeschlossen. Das Argument “zu viel Tipparbeit” greift auch an dieser Stelle nicht. Erstens ist Faulheit keine Option. Zweitens übernimmt heutzutage die IDE das Gros der Tastaturarbeit.

2. Präzision vernachlässigen

Manchmal ist die Semantik einer Benennung nicht präzise genug – was im Laufe der Zeit zu “inhaltlichen Verschiebungen” führen kann. Sie könnten etwa die Methode SaveReceipt implementieren, um eine Kopie von Belegen in der Datenbank abzulegen. Nachträglich erweitern Sie die Routine dann vielleicht um Printing und verlagern den eigentlichen Speichervorgang in eine andere Methode. Und schon führt das gewählte Naming auf den Holzweg.

Die Wahrscheinlichkeit, dass es dazu kommt, sinkt dramatisch, wenn Sie von Anfang an auf eine eindeutige Benennung im Stil von SaveReceiptToTheDatabase setzen.

3. Faulenzerei vorziehen

Naming ist zwar nicht diffizil, verlangt aber ein bisschen Denkarbeit – die Zeit kostet. Weil viele Devs sich diese nicht nehmen wollen (oder können), kommt es immer wieder zu Dummheiten wie Variablennamen, die aus einem einzelnen Buchstaben bestehen (einzige Ausnahme: i als Variable in einem Loop, aber selbst dann wäre Index die deutlich bessere Wahl). Stattdessen sollten Sie einer Variablen einen wirklich aussagekräftigen Namen zugestehen. Es mag etwas Zeit und Mühe kosten, lohnt sich aber.

Sparen Sie sich zum Beispiel so etwas:

If (EmployeeNumber > 0) and (OrderNumber > 0) { // ... }

Und gehen Sie stattdessen die Extrameile:

EmployeeIsValid = EmployeeUniqueIDInDatabase > 0; ThereIsAnOrder = OrderNumber > 0; ItIsOkayToProcessTheOrder := EmployeeIsValid and ThereIsAnOrder; If ItIsOkayToProcessTheOrder { // ... }

Das ist um Welten besser lesbar – und den Variablennamen ist klar zu entnehmen, wofür sie stehen.

4. Abkürzungen verfallen

Faulheit ist zwar keine Option, Hektik aber ebenso wenig. Denn die führt im Regelfall nur dazu, dass eindeutiges Naming unklaren und vor allem unnötigen Abkürzungen weichen muss. Die 0,876 Sekunden, die Sie mit acctBlnc im Vergleich zu accountBalance sparen, sind wertlos, wenn es dadurch zig Stunden länger dauert, den Code zu warten. Und davon abgesehen: Um welche Account Balance geht es überhaupt? Die des Unternehmens? Die des Kunden?

Auch an dieser Stelle hilft nur: Austippen. Kürzen Sie am besten einfach gar nichts ab (von Standards wie URL und http einmal abgesehen). Das kann auch dazu beitragen, die unbegründete “Angst” vor erklärendem, klaren Naming abzustreifen.

5. Funktionen schwammig benennen

Methoden sollten mit Verben benannt werden und vollständig beschreiben, was sie tun. So ist getCustomer ein guter Anfang – lässt aber Fragen offen: Woher wird der Kunde geholt? Und was genau wird dabei geholt?

Die bessere Option: getCustomerInstanceFromDatabase.

6. Konsistenz über Bord werfen

Wenn Sie Customer verwenden, um einen Kunden zu bezeichnen, der etwas am Point-of-Sale-System kauft, sollten Sie auch sicherstellen, dass dieses Naming überall zum Zuge kommt. Den Kunden in anderen Modulen als Client oder Buyer zu bezeichnen, führt ins Unglück.

Nutzen Sie dieselben Begrifflichkeiten konsistent in Ihrem gesamten Repository.

7. Ins Negativ abdriften

Insbesondere, wenn es um Booleans geht, sollten Sie auf ein positives Naming setzen, statt auf Grausamkeiten wie isNotValid oder denyAccess:

if (!IsNotValid) or (!denyAccess) { // ... }

Vermeiden Sie doppelte Verneinungen in Ihrem Code unter allen Umständen.

8. Präfixe einsetzen

In früheren Zeiten war die ungarische Notation sehr beliebt: Dabei wurden sämtliche Namen mit einem Präfix versehen, das definierte, um was es sich genau handelt. Das ist allerdings inzwischen aus der Mode gekommen, weil es zu komplex wurde. Ich für meinen Teil bevorzuge Namen, die aussagekräftig genug sind, um dem Maintainer zu vermitteln, was Sache ist. Beispielsweise handelt es sich bei EmployeeCount offensichtlich um eine Ganzzahl, bei FirstName um einen String.

Manche Devs nutzen auch ein Buchstaben-Präfix für ihre Variablennamen, um deren Rolle in einer Methode anzugeben – etwa l für lokale Variablen und a für Methodenargumente oder Parameter. Ich bin davon nicht überzeugt. Im Gegenteil: Wenn Ihre Methoden so ausufern, dass nicht auf den ersten Blick ersichtlich ist, welche Rolle eine Variable spielt, ist Refactoring angebracht.

9. Kauderwelsch nutzen

Zu vermeiden sind in Sachen Naming außerdem auch Wörter, die keine wirkliche Bedeutung aufweisen.

Sehen Sie von “Naming-Junkfood” ab wie:

Helper,

Handler,

Service,

Util,

Process,

Info,

Data,

Task,

Object oder

Stuff.

(fm)

Sie wollen weitere interessante Beiträge zu diversen Themen aus der IT-Welt lesen? Unsere kostenlosen Newsletter liefern Ihnen alles, was IT-Profis wissen sollten – direkt in Ihre Inbox!

CVE-2026-10182 | TRENDnet TEW-432BRP 3.10B20 /goform/formWlanSetup enrollee command injection (EUVD-2026-33504)

Sun, 31 May 2026 17:38:08 +0200
A vulnerability was found in TRENDnet TEW-432BRP 3.10B20 and classified as critical. The impacted element is the function formWlanSetup of the file /goform/formWlanSetup. Executing a manipulation of the argument enrollee can lead to command injection. This vulnerability only affects products that are no longer supported by the maintainer. This vulnerability is tracked as CVE-2026-10182. The attack can be launched remotely. Moreover, an exploit is present. The vendor explains: "This product has been EOL for 15 years (since 2009). As the item has been EOL for such a long time, we are not able to replicate or fix any vulnerabilities."

CVE-2026-10183 | TRENDnet TEW-432BRP 3.10B20 /goform/formWlanSetup enrollee stack-based overflow (EUVD-2026-33505)

Sun, 31 May 2026 17:38:07 +0200
A vulnerability was found in TRENDnet TEW-432BRP 3.10B20. It has been classified as critical. This affects the function formWlanSetup of the file /goform/formWlanSetup. The manipulation of the argument enrollee leads to stack-based buffer overflow. This vulnerability only affects products that are no longer supported by the maintainer. This vulnerability is listed as CVE-2026-10183. The attack may be initiated remotely. In addition, an exploit is available. The vendor explains: "This product has been EOL for 15 years (since 2009). As the item has been EOL for such a long time, we are not able to replicate or fix any vulnerabilities."

CVE-2026-10181 | TRENDnet TEW-432BRP 3.10B20 /goform/formSysCmd submit-url stack-based overflow (EUVD-2026-33503)

Sun, 31 May 2026 17:37:58 +0200
A vulnerability has been found in TRENDnet TEW-432BRP 3.10B20 and classified as critical. The affected element is the function formSysCmd of the file /goform/formSysCmd. Performing a manipulation of the argument submit-url results in stack-based buffer overflow. This vulnerability only affects products that are no longer supported by the maintainer. This vulnerability is identified as CVE-2026-10181. The attack can be initiated remotely. Additionally, an exploit exists. The vendor explains: "This product has been EOL for 15 years (since 2009). As the item has been EOL for such a long time, we are not able to replicate or fix any vulnerabilities."

CVE-2026-10180 | TRENDnet TEW-432BRP 3.10B20 /goform/formSysCmd sysCmd command injection (EUVD-2026-33500)

Sun, 31 May 2026 16:09:00 +0200
A vulnerability, which was classified as critical, was found in TRENDnet TEW-432BRP 3.10B20. Impacted is the function formSysCmd of the file /goform/formSysCmd. Such manipulation of the argument sysCmd leads to command injection. This vulnerability only affects products that are no longer supported by the maintainer. This vulnerability is referenced as CVE-2026-10180. It is possible to launch the attack remotely. Furthermore, an exploit is available. The vendor explains: "This product has been EOL for 15 years (since 2009). As the item has been EOL for such a long time, we are not able to replicate or fix any vulnerabilities."

CVE-2026-10179 | TRENDnet TEW-432BRP 3.10B20 formSetWlanEncrypt webpage stack-based overflow (EUVD-2026-33499)

Sun, 31 May 2026 16:08:53 +0200
A vulnerability, which was classified as critical, has been found in TRENDnet TEW-432BRP 3.10B20. This issue affects the function formSetWlanEncrypt of the file /goform/formSetWlanEncrypt. This manipulation of the argument webpage causes stack-based buffer overflow. This vulnerability only affects products that are no longer supported by the maintainer. The identification of this vulnerability is CVE-2026-10179. It is possible to initiate the attack remotely. Furthermore, there is an exploit available. The vendor explains: "This product has been EOL for 15 years (since 2009). As the item has been EOL for such a long time, we are not able to replicate or fix any vulnerabilities."

CVE-2025-9165 | LibTIFF 4.7.0 tiffcmp tools/tiffcmp.c memory leak (728/729 / Nessus ID 254437)

Sun, 31 May 2026 14:09:24 +0200
A vulnerability described as problematic has been identified in LibTIFF 4.7.0. This affects the function _TIFFmallocExt/_TIFFCheckRealloc/TIFFHashSetNew/InitCCITTFax3 of the file tools/tiffcmp.c of the component tiffcmp. Executing a manipulation can lead to memory leak. This vulnerability is tracked as CVE-2025-9165. The attack is restricted to local execution. Moreover, an exploit is present. There is ongoing doubt regarding the real existence of this vulnerability. It is best practice to apply a patch to resolve this issue. A researcher disputes the security impact of this issue, because "this is a memory leak on a command line tool that is about to exit anyway". In the reply the project maintainer declares this issue as "a simple 'bug' when leaving the command line tool and (...) not a security issue at all".

The Servo Blog: April in Servo: new Android UI, focus, forms, security fixes, and more!

Sun, 31 May 2026 13:08:28 +0200

Servo 0.2.0 contains all of the changes we landed in April, which came out to yet another record 534 commits (March: 530). For security fixes, see § Security.

Note: the GitHub release is available now, but the crates.io release is not yet complete. We expect to publish it some time next week.

`, ` (@lukewarlow, @mrobinson, #43189)