An anonymous reader quotes a report from TechCrunch: A group made up of dozens of cybersecurity experts, including several well-known veterans of the industry, published an open letter to the U.S. government asking it to lift the export control order on Anthropic's Fable and Mythos models. According to the open letter, "this action has taken the best models away from [cybersecurity] defenders" who now can't use the models to find vulnerabilities and make their software and products more secure. "To pull the best capabilities away from defenders without a good reason when our adversaries are rapidly advancing is dangerous," read the letter.

On Friday, the U.S. government ordered Anthropic to limit the export of Fable and Mythos, citing national security concerns, without explaining the specific reasons behind the order, according to Anthropic. In response, the company suspended access to the models to all users worldwide. As of this writing, the letter is signed by 76 cybersecurity experts, including Alex Stamos, former Facebook chief of security; Casey Ellis, the founder bug bounty platform Bugcrowd; Jon Callas, famed cryptographer and former Apple security design and architecture manager; Paul Vixie, computer scientist ; Dino Dai Zovi, the former head of applied security engineering at Block; Katie Moussouris, the founder of Luta Security; and Rachel Tobac, the CEO of the security awareness training firm SocialProof Security.

[...] Anthropic said that the White House export control order may have been based on a report that there was a method to bypass -- or jailbreak -- Fable to unlock its powerful Mythos-level capabilities. According to Katie Moussouris, one of the signatories of the open letter, the method was demonstrated by Amazon researchers in a paper that is not public but that she has reviewed. But Moussouris said in a blog post that the paper did not actually demonstrate a real jailbreak. Instead, she wrote, the researchers simply asked Fable to fix open source code with public and known vulnerabilities along with "deliberately planted vulnerabilities," after the model initially refused to "review the code for security issues."

"The behavior described in the paper cannot meaningfully be fixed, and any attempt would only weaken the model for defense," Moussouris wrote. "Defenders need to be able to ask AI to fix the bugs in a file, explain why the fix matters, and write tests that confirm the patch works. That is not a guardrail bypass. It is the most valuable thing an AI model can do for defensive security: executing the find, fix, and test loop defenders run every day." Moussouris' critique was echoed in the open letter, which also said that the group of experts believe the model capabilities in the Amazon paper "can be replicated" on OpenAI's GPT-5.5, on Anthropic's own publicly available Claude Opus 4.8 and Sonnet, "and even Chinese models like Kimi 2.7."

Moussouris told TechCrunch that "the bugs used to demonstrate the techniques in the paper can be found using the other models. The method in the paper is a guardrail bypass technique. Other models that lack the Fable guardrails often won't refuse the straightforward request to look for security bugs, so they don't need a bypass." The letter also asked for transparently and fairly enforced regulations created by "a democratic rule-making process" that are based on scientific research done by industry and academic experts, and "used only to the minimal extent necessary to ensure the safety of the American public."

An anonymous reader quotes a report from Ars Technica: A decade ago, AMD added a protection to its high-end CPUs to protect them against cold boot attacks and other types of physical exploits that siphon sensitive data out of the connected memory chips. Short for Transparent Secure Memory Encryption, TSME encrypts the entire contents stored in memory, making the data useless to physical attackers. Over time, AMD added TSME to lower-end processors, including the consumer version of its Ryzen chips, a CPU that costs less than the Pro version. Over the years, users of these lower-end chips have gotten used to the added security. Recently and without warning or notice, this lower-end line of AMD chips suddenly dropped the protection, and did so in a way that was impossible to detect on Windows machines and required a fair amount of technical work when using Linux.

AMD has yet to say why TSME worked on these CPUs, or even to confirm the change. AMD declined to answer questions sent by email other than to say TSME "is a security feature only applied to PRO CPUs as part of AMD PRO Technologies." The statement is the first known time the chipmaker has explicitly made this restriction public. [...] There's no indication that AMD ever advertised or marketed TSME as being available in consumer CPUs. AMD has long said that a related memory protection, Secure Memory Encryption (SME), is available only in the Pro and Epyc CPU tiers. SME is OS-managed. It uses a single key and allows the OS to selectively encrypt individual memory pages. TSME is firmware-managed. It encrypts all RAM with no OS involvement. When active, it provides protection against physical attacks, including cold boot exploits, DRAM interface snooping, and memory module removal. It activates silently when enabled in the BIOS, making it the more practically useful of the two protections. Ben Kilpatrick, a self-described "privacy-conscious Linux hobbyist," discovered that TSME had stopped working on his consumer Ryzen processor despite remaining enabled in the BIOS. He spent months investigating, persuaded MSI engineers to test multiple CPUs, motherboards, and firmware versions, and filed a public AMD bug report that traced the change to newer AGESA firmware apparently disabling TSME on consumer chips while retaining it on Pro and EPYC models.

"AMD engineers' comments, such as those mentioned above, and the years of TSME working just fine in the lower-cost tier processors, have understandably conditioned Kilpatrick and other users to reasonably regard it as an expected part of the chip package," reports Ars Technica. "AMD quietly removing it and providing no acknowledgment or explanation strikes these users as something of a betrayal."

Joe Fitzgerald, an expert in silicon-level security, said in an interview: "They could have not realized they did it leading to their cagey responses, or they could have done it intentionally and tried to get away with it, leading to the same cagey responses. But I really feel like an explanation should be in order, even if it was 'TSME was never supposed to be supported. We did ship some firmwares that erroneously enabled it, but you shouldn't use them since we can't guarantee it'll work properly.'"

This month saw the release of Vim Classic 8.3, the first stable version of a new long-term support fork of Vim maintained without generative AI tools. Linuxiac reports: The release is based on Vim 8.2.0148 and includes selected bug fixes and patches backported from later upstream Vim releases. Vim Classic was first announced by [SourceHut's CEO/founder] Drew DeVault in March 2026 after he objected to LLM-assisted development in Vim and Neovim. In his announcement, DeVault said he no longer wanted to use software developed with LLM assistance and introduced Vim Classic as a fork for users who want to continue using Vim without that involvement... Vim Classic follows Vim's charityware model and continues to direct users toward Bram Moolenaar's long-running support for children in Uganda. The release is distributed as a signed source tarball from SourceHut, while future important announcements are expected through the project's mailing list.
"Vim is important to me..." DeVault wrote in March. (DeVault even tattooed "hjkl" on his right arm.) "[A]lmost every word I have ever committed to posterity, through this blog, in my code, all of the docs I've written, emails I've sent, and more, almost all of it has passed through Vim."

But DeVault wrote that he also cares about AI's impact on air pollution, fresh water supplies, global supply chains, and the working conditions of miners in African companies: And at a moment when the climate demands immediate action to reduce our footprint on this planet, the AI boom is driving data centers to consume a full 1.5% of the world's total energy production in order to eliminate jobs and replace them with a robot that lies... All this to enrich the few, centralize power, reduce competition, and underwrite an enormous bubble that, once it bursts, will ruin the lives of millions of the world's poor and marginalized classes.

I don't think it's cute that someone vibe coded "battleship" in VimScript. I think it's more important that we stop collectively pretending that we don't understand how awful all of this is. I don't want to use software which has slop in it. I do what I can to avoid it, and sadly even Vim now comes under scrutiny in that effort as both Vim and NeoVim are relying on LLMs to develop the software... To keep my conscience clear, and continue to enjoy the relationship I have with this amazing piece of software, I have forked Vim...

Since forking from this base, I have backported a handful of patches, most of which address CVEs discovered after this release, but others which address minor bug fixes. I also penned a handful of original patches which bring the codebase from this time up to snuff for building it on newer toolchains...

I invite you to use Vim Classic, if you feel the same way as me, and to maintain it with me, contributing the patches you need to support your own use cases.

Longtime Slashdot reader Dotnaught shares a report from The Register: For the past 90 days, Microsoft has been quietly patching a firmware flaw in Surface devices that allowed the hardware to be bricked with a single packet, though only for those who have disabled Secure Core and Secure Boot. And the company's Copilot AI software inadvertently helped identify the faulty firmware.

According to Jack Darcy, a security researcher based in Australia, his instance of Microsoft Copilot stumbled across the bug after being asked to adjust the screen backlighting on a Surface device. The Copilot-conjured Python script ended up rendering the researcher's laptop inoperable by overwriting the embedded controller firmware. "Copilot autonomously created and executed four progressively aggressive Python scripts during a probe for backlight control values that sent raw SSAM ioctl commands (SSAM_CDEV_REQUEST = 0xC028A501) directly to the SAM microcontroller through the SAM software path," Darcy explained to The Register.

[...] "We appreciate the work of Jack Darcy and The Register for reporting this issue under a coordinated vulnerability disclosure," a Microsoft spokesperson said in a statement. "Our investigation found that a deprecated UEFI interface could trigger a boot loop on some devices. To trigger this loop, the user must have administrator privileges and have already disabled the Secure Boot security feature. We have released updates to address the issue for most impacted devices."

That means managed devices are not at risk. But those using Linux, or Windows users who have disabled Secure Core and Secure Boot for gaming, or who use custom Windows drivers, or who have USB boot enabled, may still be vulnerable if their systems haven't received the update. We're uncertain about the range of Surface devices affected. Our source said it appears to be all of them (Surface Laptops 3-6, Surface Book 1-3) except for Surface Go models. ARM variants, however, have not been tested. The report notes that Microsoft is planning to move the Surface stack to a more secure architecture based on Rust code.

"Our most recent Surface for Business hardware features a major architectural shift in terms of improved reliability and security that spans our embedded controller, UEFI, but also some of our drivers," said David Abzarian, chief architect for Microsoft Surface. "We're investing in the most secure foundation for a PC by building our embedded controller firmware from the ground up in Rust (as part of leveraging and contributing to the Open Device Partnership (ODP)) in addition to a rewrite of the UEFI DXE Core in Rust; these projects are known as Secure EC and Project Patina respectively."

"We're also not only shipping some of our drivers written in Rust, but also helping co-develop the framework Windows Drivers in Rust (WDR) to help enable a broad set of partners in the Windows ecosystem to capitalize on these benefits. I will also note that all of these efforts are open-source promoting one of our key security principles around transparency."

The Asahi Linux team is warning Apple Silicon users not to upgrade to the macOS 27 beta because Apple's changes to the boot picker and Startup Disk app make Asahi partitions invisible, preventing Linux from booting. The Register reports: The team added: "If you insist on trying out macOS 27 as soon as possible, please ensure you install a secondary copy of macOS 26 first, or install macOS 27 itself on a secondary volume." They've also updated the installer to prevent installs from running on macOS 27 for now. For anyone who ignored all of the above, "we will not support users who have installed the macOS 27 beta without ensuring at least one stable version of macOS is installed."

Considering macOS 27 is in beta, the issue may be accidental rather than an attempt by Apple to block Linux on its hardware. The Asahi team said it has filed bug report. The good news for anyone who pulled the trigger on installing the macOS 27 beta is that although the partition might not be visible, it hasn't gone anywhere. The Asahi team wrote: "If you have already upgraded to the beta and noticed that your Asahi partition has disappeared, do not stress. Your Asahi partition is still there, and you have not lost any data."

An anonymous reader quotes a report from Ars Technica: Researchers have analyzed a high-severity vulnerability in Linux that's able to escalate untrusted users to root by exploiting a bug you don't often see: a single errant character inside the kernel. The vulnerability, tracked as CVE-2026-23111, is located in nf_tables, a subsystem of the Linux kernel that provides packet filtering capabilities. It's used to manage firewall rules and replaces older subsystems such as iptables, ip6tables, arptables, and ebtables.

The presence of a single mis-issued exclamation point in code implementing nf_tables introduced a use-after-free, a class of vulnerability that corrupts memory by placing malicious code at memory addresses that haven't been properly freed of their previous contents. CVE-2026-23111 can be exploited by an unprivileged user or process to elevate system rights to root. The exploit works by disrupting the deletion of verdicts -- a determination within the nf_tables framework that determines if a packet matches a rule calling for a certain action to be performed. This process can use what are known as catchall elements, which act as a wildcard in the event a lookup doesn't match any other element in the set.

When a verdict map is deleted from memory, catchall elements are deactivated and a chain's reference counter is decremented. When errors occur the deletion can be reversed and the counter incremented. CVE-2026-53111 allows for that process to be altered. As a result, the exploit can decrement the variable an arbitrary number of times and then delete and free the chain when some objects still point to it. Although the kernel vulnerability was fixed in February, multiple proof-of-concept exploits have since emerged, including one from FuzzingLabs in April and another from Exodus Intelligence that works on Debian and Ubuntu.

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." Our first target was LibJS , Ladybirdâ(TM)s JavaScript engine... 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.

Bitcoin briefly fell below $60,000 on Friday, "extending its weekly loss to nearly 20% and threatening to fall below $59,000," reports CoinDesk. Crypto was also hit by a 40%-plus plunge in Zcash after Shielded Labs disclosed a years-old bug that could have allowed undetected counterfeit ZEC creation. From the report: Now, with stocks in plunge mode -- the Nasdaq down nearly 4% on Friday -- bitcoin finds itself perfectly correlated. "Short term, Bitcoin feels like swallowing broken glass," wrote Jeff Swanson Friday. "The chart goes up. It goes down. It makes grown men cry into their Robinhood accounts and CNBC anchors smugly declare the funeral, for the eleventh time." "Here's what uncomfortable people don't understand: the discomfort is the yield. Every paper-handed panic seller is handing their future to someone with a longer time horizon and a colder storage device."

[...] Earlier, Shielded Labs, a nonprofit developer on the privacy token system, disclosed a critical vulnerability in Zcash's (ZEC) Orchard privacy pool that could have threatened the integrity of the token's supply. The vulnerability, if exploited, could have allowed an attacker to create an unlimited number of counterfeit ZEC tokens, completely undetected. "Think of it as someone secretly gaining access to the Federal Reserve's dollar printing press, except in this case, even the Fed wouldn't be able to tell these extra dollars were printed," wrote Omkar Godbole. Importantly, the vulnerability was discovered with help from Anthropic's recently released Opus 4.8 AI model, raising difficult questions for the entire crypto industry. More to come on that. ZEC is now down 42% over the past 24 hours. On Wednesday, the Zcash Foundation said: "The vulnerability was caught before any known exploitation occurred. There is no evidence of unauthorized value creation. Zcash's turnstile mechanism (which tracks the total ZEC balance across all value pools) confirmed that the total supply remained intact throughout. User privacy was not affected. Sapling and transparent transactions continued operating normally throughout the incident."

An anonymous reader quotes a report from The Guardian: Bumblebees can use tools to solve a problem, according to experiments that demonstrate their remarkably advanced cognitive abilities. The bees were given an adapted version of an experiment that, 100 years ago, first demonstrated chimpanzees could work out how to retrieve an out-of-reach banana by stacking boxes. Since then, various other primates, elephants and crows have joined an elite cohort of species known to be capable of this level of insight and spontaneous problem solving. In the latest research, bees were shown to be able to roll a polystyrene ball to a specific location and climb on to it in order to access an artificial flower on a low ceiling. The findings challenge the longstanding assumption that insects operate purely on instinct and mindless trial-and-error learning. "Most people think insects are reflex-based machines," said Dr Olli Loukola, a behavioral ecologist at the University of Oulu, Finland, and senior author. "That they can't have any emotional states or feel pain. Some people don't even realize that they have brains. I hope that these results change the worldview about that."

"We are not claiming that bees think like humans," added Loukola. "But our findings show that miniature brains can generate flexible solutions to novel problems in ways we are only beginning to understand."

The findings are published in the journal Science.

BrianFagioli writes: Fedora Linux 43 users upgrading to the latest Dovecot mail server discovered something rather unsettling: some older Microsoft Outlook configurations may have been silently ignoring SSL/TLS settings for POP3 email connections for years. According to a Fedora community blog post, affected Outlook clients reportedly continued using insecure port 110 connections even when encryption was enabled in the application settings. The issue surfaced after Dovecot 2.4 disabled plaintext authentication on non secure connections by default, causing Outlook users to suddenly lose mailbox access after the Fedora 43 upgrade.

The report suggests the behavior may date back as far as Outlook 2007, although modern Outlook builds were not fully tested. Fedora admins stress that the problem could be limited to legacy account configurations rather than current versions of Outlook itself. Still, the discovery has sparked discussion among Linux admins and security folks because many users likely assumed their email traffic was encrypted simply because Outlook claimed SSL/TLS was enabled. The incident also highlights how stricter defaults in modern open source infrastructure can expose ancient assumptions and questionable behaviors that quietly survived for decades.

Google has asked the EPA for permission to release up to 32 million sterile male mosquitoes in California and Florida over two years. The effort is part of the company's Debug program, which uses Wolbachia-infected males to reduce populations of disease-spreading Aedes aegypti mosquitoes. Google cites a similar approach in Singapore that helped suppress mosquito populations and reduce dengue cases. The Guardian reports: As part of its successful "Debug" program, Google is tapping into its tech expertise to raise an army of sterile male mosquitoes to lower the number of illness-spreading bugs. Mosquitoes -- the world's deadliest animal -- kill more people than any other creature in the world every year by spreading lethal diseases such as dengue, West Nile virus, Zika, chikungunya and malaria.

A notice (PDF) from the federal register shows the US Environmental Protection Agency (EPA) is reviewing Google's request to release up to 16 million mosquitoes annually, in Florida and California, over the span of two years. The EPA will decide whether to greenlight Google's request for an experimental use permit after a public comment period, which ends on 5 June.

Male mosquitoes don't bite or carry disease. One of the main approaches Google is testing involves rearing male mosquitoes with a naturally occurring bacteria, called wolbachia, which stops them from having offspring with wild female mosquitoes. When an infected male tries to mate with a wild female, her eggs won't hatch; Google explains in a blog post: "the population gets smaller with each generation."

"A security researcher published a series of unpatched bugs in Microsoft products," reports TechCrunch, "along with code to exploit them."

Microsoft's response to the researcher? "Threatening to take legal action and call the cops on them." On Wednesday, Microsoft published a blog post criticizing the researcher, who goes by the handle "Nightmare Eclipse," for publicly disclosing a series of bugs, including BlueHammer, RedSun, UnDefend, and YellowKey. The flaws affected products such as the Windows built-in antivirus engine Defender and the disk-encryption tool BitLocker.

The core of Microsoft's complaints is that the researcher did not attempt to report the bugs so that the company could fix them. That would have been "responsible," as Microsoft's blog put it. The other side of the company's argument is that by publishing the details of the bugs and how to exploit them before they were patched, Nightmare Eclipse may have aided malicious hackers. Some of the vulnerabilities Nightmare Eclipse disclosed have since been used by hackers in real-world attacks, according to Microsoft, as well as the U.S. cybersecurity agency CISA. "Our Digital Crimes Unit will continue bringing cases against these actors and those that enable their criminal activity — coordinating as needed with law enforcement around the world," Microsoft wrote...

In a series of blog posts published in the last couple of weeks — without providing many specific details — Nightmare Eclipse claimed to have been in contact with Microsoft, but the company allegedly mistreated them, including revoking access to their Microsoft Security Response Center account, the portal where researchers can report vulnerabilities to the tech giant. Nightmare Eclipse's implication was that they had no choice but to release the vulnerabilities publicly... The researchers published the bugs on open source repositories GitHub (owned by Microsoft) and GitLab. The researchers' accounts on those platforms have been banned...

In response to this latest controversy with Nightmare Eclipse, countless researchers have shared their bad experiences reporting bugs to Microsoft.
Thanks to long-time Slashdot reader Elektroschock for sharing the news.

Linux stable kernel maintainer Greg Kroah-Hartman says Rust can help Linux deal with a flood of AI-discovered security bugs (namely Dirty Frag, Copy Fail, and Fragnesia) by preventing common C mistakes around memory, locking, error handling, and untrusted data at build time rather than during human review. It's "not a silver bullet" and does not mean rewriting the whole kernel, but he said new drivers and subsystems will increasingly use Rust as Linux evolves forward. ZDNet reports: Kroah-Hartman illustrated those pitfalls with real C bugs in the kernel, including a 15-year-old Bluetooth bug that dereferenced a pointer without checking it and a Xen bug where "we forgot to unlock" in an error path. "The majority of the bugs in the kernel are this tiny, minor stuff," he explained. "Error conditions aren't checked, locks aren't forgotten, unreleased memories leak, and vulnerabilities add up over time. They crash the kernel. This is what we live with in C. This is why we don't like it." Kroah-Hartman argued that the "best beauty of Rust" is catching those mistakes at build time rather than in review. For example, when it comes to locking, he highlighted Rust's locking abstractions in the kernel: "The only way you can get access to inner pointers of structures is by grabbing that lock, and releasing the lock automatically. The compiler does it, it's guarded, the lock happens, everything's happy. You just can't write code to access these values...without grabbing the lock. The compiler will not let you."

Those properties, he argued, directly remove a huge fraction of the bugs he sees: "This is going to save us those two things. First, 60% of the bugs in the kernel right there, they're gone. Thank you." The payoff is earlier, more automated enforcement: "If this happens at build time, not review time, don't make me a maintainer who has to read your code [and] say, 'Oh, then you properly check that error value. Oh, did you properly grab the locks in the right spot?' Rust gives us that for free. This is the best thing ever." Even if Rust vanished tomorrow, Kroah-Hartman argued, it has already forced the kernel to clean up C code and interfaces. He credited Rust's influence outright: "We stole this from Rust. Thank you. It's a good idea, so if Rust disappeared tomorrow, we have cleaned up the C code in the kernel so much and taken in the ideas. We thank you, you've made Linux better with it just by existing."

[...] What ultimately sold a number of core maintainers, including him, on Rust was how it "makes reviewing code easier." With CI [Continuous Integration] bots enforcing builds and Rust's type system enforcing key invariants, maintainers can "focus on the logic" rather than resource bookkeeping: "I can care about that one function. I don't have to worry about the rest of this stuff, because I assume that it works properly, because it was built properly." Internally, he said, the top maintainers have already made their call on Rust's status: "The Linux kernel maintainers, we get together every year and talk about what the processes are doing. Last year, we said the Rust experiment is over. It's not an experiment. This is for real." The rationale: "The people behind it are real. We trust them. We know what they're doing. They've shown and put in the work to make Rust a viable language in the kernel, and we're going to make this stick. Let's go full speed ahead. And, as always," he said wryly, "world domination proceeds." "If you never remember anything else in my talk, just remember these four words. It came from Microsoft Security many, many years ago," Kroah-Hartman told attendees. "They realized all input is evil. You have to validate all input."

wiredmikey shares a report from SecurityWeek: Anthropic says its Claude Mythos model discovered thousands of severe vulnerabilities across more than 1,000 open source software (OSS) projects. According to the AI giant, Mythos Preview has identified more than 23,000 potential vulnerabilities. Of these, 1,900 have been reviewed by external security firms, and 1,726 have been confirmed, including over 1,000 rated "high" or "critical" severity.

The findings are still being reviewed, and Anthropic estimates that nearly 3,900 critical and high-severity vulnerabilities will be confirmed based only on current findings. As the scans are ongoing, the company believes the number of severe vulnerabilities may reach 6,200. Anthropic says more than 1,100 unverified findings have been reported to vendors, and 75 issues with a critical or high severity rating have been patched. Vendors have published 65 security advisories. "The number of patches is still relatively low for three reasons. First, we're still early in the 90-day window that's set out in our Coordinated Vulnerability Disclosure policy: we expect many more patches to land soon," the AI company explained.

"Second, we are likely to be undercounting patches because some vulnerabilities are patched without a public advisory: in those cases, we're reliant on scanning for the patches ourselves using Claude. Third, the low volume of patches reflects a genuine problem: even at our relatively slow pace of disclosures, Mythos Preview is adding to an already-overloaded security ecosystem," it added.

"Canonical says Ubuntu Pastebin will be decommissioned at the end of May 2026," writes Slashdot reader BrianFagioli, "as part of an infrastructure modernization effort." The announcement only appeared this week, giving the Linux community barely any warning before a service that has been tied to Ubuntu support culture for years suddenly disappears.

Ubuntu Pastebin has long been used for sharing logs, crash reports, config files, and terminal output across IRC, Ask Ubuntu, forums, bug reports, Reddit, and countless troubleshooting guides scattered around the internet. The bigger concern is link rot. Once the shutdown happens, years of old support discussions could lose critical debugging information overnight. Community members have already pointed out that some Ubuntu packages and scripts still reference paste.ubuntu.com directly.

While it is understandable that aging services eventually get retired, the extremely short transition period is rubbing many Linux users the wrong way, especially in a community where old documentation and archived troubleshooting threads still regularly help people solve problems a decade later.

Linus Torvalds spoke this week at the Linux Foundation's Open Source Summit North America, reports ZDNet — and described how AI is impacting Linux kernel development: "In the last six months, we've seen a lot more commits," Torvalds noted, estimating that "the last two releases, it's been about 20% more commits than we had in the previous releases over many years.... The real change that happened in the last six months was that the AI tools actually got good enough for a lot of people... we're seeing a definite uptick in just development on pretty much all fronts...."

On the positive side, he framed AI-discovered bugs as "short-term pain" with long-term benefits: "When AI finds a bug in any source code... long term is you found a bug, we fixed it, that the end result is better for it." After all, he continued, "I think finding bugs is great, because the real problem is all the bugs you didn't find..." For small teams or solo maintainers, he said, flood-style AI bug reports can cause real burnout, especially when "it's a bug report, and when you ask for more information, the person has done a drive-by and doesn't even answer your questions anymore."
The AI news site Techstrong notes this quote from Torvalds. "I have a love-hate relationship with AI. I actually really like it from a technical angle, I love the tools, I find it very useful and interesting, but it is definitely causing pain points." The chief challenge with AI is that it forces people to change how they work, he found. People get into a rut, and AI challenges their norm. The Linux security mailing list got the brunt of this new wave of AI-generated commits. Not all bugs are security issues, but when "people think that when they find a bug with AI, the first reaction seems to sometimes be let's send it to the security list, because this may have security implications," Torvalds said. As a result, the security list — watched over by a small group of maintainers — was overrun by duplicate entries...

The Linux project learned to manage the bug influx with a set number of tools to sort out and deprioritize the obvious drive-by reports (ones where the person submitting the report won't even answer any questions). One tool, Sashiko, reviews all the patches submitted on the mailing list. "Sometimes the review is not great, but quite often it finds issues and it asks questions and says, 'Hey, what about this issue?'" he said.
Linux also updated their documentation, partly just to address "an uptick in bug and security reports from discoveries made in full or in part with AI."

Qualys's Threat Research Unit (TRU) has discovered and published a logic flaw in Linux kernel "that permits an unprivileged local user to disclose sensitive files and execute arbitrary commands as root on default installations of several major distributions." Friday their blog pointed out "The bug has resided in mainline Linux since November 2016 (v4.10-rc1)."

"Upstream patches and distribution updates are already available." Working exploits are circulating publicly, and administrators should apply vendor kernel updates without delay. During ongoing research into Linux kernel privilege boundaries, TRU identified a narrow window in which a privileged process that is dropping its credentials remains reachable through ptrace-family operations even though its dumpable flag should have closed that path. By pairing this window with the pidfd_getfd() syscall (added in v5.6-rc1, January 2020), an attacker can capture open file descriptors and authenticated inter-process channels from a dying privileged process and re-use them under their own uid. The primitive is reliable and turns any local shell into a path to root or to sensitive credential material [including host private keys under /etc/ssh ]

CVE-2026-46333 is local-only, but the impact is severe... Any unprivileged shell on a vulnerable host is enough to read /etc/shadow, exfiltrate SSH host private keys, or execute arbitrary commands as root through hijacked dbus connections to systemd. In practice, the distinction between an unprivileged foothold and full host compromise collapses: a phished developer account, a constrained CI runner, a low-privilege service account, or a shared multi-tenant host all become direct paths to root. With the vulnerable code shipping in mainline kernels since v4.10-rc1 (November 2016), the historical exposure spans nine years of enterprise fleets, cloud images, and container hosts.

Qualys followed responsible disclosure throughout. Qualys reported the vulnerability privately to the upstream Linux kernel security contact on 2026-05-11. Over the following three days the kernel security team developed and reviewed the fix, CVE-2026-46333 was assigned, and the patch was committed publicly on 2026-05-14. We then engaged the linux-distros mailing list, the standard pre-disclosure channel for downstream coordination. A short time later, an independent exploit derived from the public kernel commit appeared.... Qualys is releasing the complete advisory today because the underlying technique is novel, the public picture is now incomplete and uneven, and independent researchers have already achieved local root and published exploit material. Doing so gives defenders, detection engineers, and downstream maintainers a single authoritative reference for the flaw, the race against do_exit(), the role of pidfd_getfd(), and the four exploitation case studies.

An anonymous reader quotes a report from Ars Technica: Google on Wednesday published exploit code for an unfixed vulnerability in its Chromium browser codebase that threatens millions of people using Chrome, Microsoft Edge, and virtually all other Chromium-based browsers. The proof-of-concept code exploits the Browser Fetch programming interface, a standard that allows long videos and other large files to be downloaded in the background. An attacker can use the exploit to create a connection for monitoring some aspects of a user's browser usage and as a proxy for viewing sites and launching denial-of-service attacks. Depending on the browser, the connections either reopen or remain open even after it or the device running it has rebooted.

The unfixed vulnerability can be exploited by any website a user visits. In effect, a compromise amounts to a limited backdoor that makes a device part of a limited botnet. The capabilities are limited to the same things a browser can do, such as visit malicious sites, provide anonymous proxy browsing by others, enable proxied DDoS attacks, and monitor user activity. Nonetheless, the exploit could allow an attacker to wrangle thousands, possibly millions, of devices into a network. Once a separate vulnerability becomes available, the attacker could use it to then compromise all those devices.

"The dangerous part here is that you can just have a lot of different browsers together that you can in the future run something on that you figure out," said Lyra Rebane, the independent researcher who discovered the vulnerability and privately reported it to Google in late 2022 in an interview. He said using the exploit code Google prematurely published would be "pretty easy," although scaling it to wrangle large numbers of devices into a single network would require more work. In the thread of Rebane's disclosure to Google, two developers said in separate responses that it was a "serious vulnerability." Its severity was rated S1, the second-highest classification.

Since its reporting 29 months ago, the vulnerability remained unknown except to Chromium developers. Then on Wednesday morning, it was published to the Chromium bug tracker. Rebane initially assumed the vulnerability was finally fixed. Shortly thereafter, he learned that, in fact, it remained unpatched. While Google removed the post, it remains available on archival sites, along with the exploit code. Google representatives didn't immediately respond to an email asking how and why it published the vulnerability and if or when a fix would become available. The exploit works by abusing Chromium's Browser Fetch API to open a service worker that remains persistently active. A malicious website can trigger it through JavaScript, creating a connection that can be used "for monitoring some aspects of a user's browser usage and as a proxy for viewing sites and launching denial-of-service attacks," reports Ars.

Depending on the browser, those connections "either reopen or remain open even after it or the device running it has rebooted," effectively turning the device into part of a "limited botnet."

A researcher known as Chaotic Eclipse has released a proof-of-concept exploit for a new Windows zero-day dubbed MiniPlasma, which BleepingComputer confirmed can grant SYSTEM privileges on fully patched Windows 11 systems. The researcher claims the bug is effectively a still-exploitable version of a 2020 flaw Microsoft said it had fixed. From the report: At the time, the flaw was assigned the CVE-2020-17103 identifier and reportedly fixed in December 2020. "After investigating, it turns out the exact same issue that was reported to Microsoft by Google project zero is actually still present, unpatched," explains Chaotic Eclipse. "I'm unsure if Microsoft just never patched the issue or the patch was silently rolled back at some point for unknown reasons. The original PoC by Google worked without any changes."

BleepingComputer tested the exploit on a fully patched Windows 11 Pro system running the latest May 2026 Patch Tuesday updates. In our test, we used a standard user account, and after running the exploit, it opened a command prompt with SYSTEM privileges, as shown in the image [here]. Will Dormann, principal vulnerability analyst at Tharros, also confirmed the exploit works in his tests on the latest public version of Windows 11. However, he said that the flaw does not work in the latest Windows 11 Insider Preview Canary build.

The exploit appears to abuse how the Windows Cloud Filter driver handles registry key creation through an undocumented CfAbortHydration API. Forshaw's original report said that the flaw could allow arbitrary registry keys to be created in the .DEFAULT user hive without proper access checks, potentially enabling privilege escalation. While Microsoft reports having fixed the bug as part of its December 2020 Microsoft Patch Tuesday, Chaotic Eclipse now claims the vulnerability can still be exploited.

Today Linus Torvalds announced another Linux release candidate on the kernel mailing list. But he also highlighted "documentation updates" to address a new problem.

"The continued flood of AI reports has basically made the security list almost entirely unmanageable, with enormous duplication due to different people finding the same things with the same tools." (The new documentation says the security team has found "bugs discovered this way systematically surface simultaneously across multiple researchers, often on the same day.") TORVALDS: People spend all their time just forwarding things to the right people or saying "that was already fixed a week/month ago" and pointing to the public discussion.

Which is all entirely pointless churn, and we're making it clear that AI-detected bugs are pretty much by definition not secret, and treating them on some private list is a waste of time for everybody involved — and only makes that duplication worse because the reporters can't even see each other's reports.

AI tools are great, but only if they actually help, rather than cause unnecessary pain and pointless make-believe work. Feel free to use them, but use them in a way that is productive and makes for a better experience.

The documentation may be a bit less blunt than I am, but that's the core gist of it.
The new documentation offers this overview. "It turns out that the majority of the bugs reported via the security team are just regular bugs that have been improperly qualified as security bugs due to a lack of awareness of the Linux kernel's threat model."

"So just to make it really clear," Torvalds said at the end of his post. "If you found a bug using AI tools, the chances are somebody else found it too.

"If you actually want to add value, read the documentation, create a patch too, and add some real value on *top* of what the AI did. Don't be the drive-by 'send a random report with no real understanding' kind of person. Ok?"