Roastidio.us in webspace https://www.theregister.com/

Anthropic admits it dumbed down Claude with 'úpgrades' • The Register

Sun, 26 Apr 2026 01:10:43 +0000

Claude users who complained about the AI service producing lower-quality responses over the past month weren’t imagining it.

Anthropic on Thursday published the results of a company investigation that found three distinct changes in March and April made things worse for customers using Claude Code, the Claude Agent SDK, and Claude Cowork.

Claude's API, the company says, was not affected.

Claude users complained bitterly about the quality of Claude's output during March and April, and service availability problems only made matters worse.

Anthropic insists it didn't degrade its models intentionally. Rather, several adjustments went awry and those missteps created the perception of creeping AI incompetency.

First, on March 4, Anthropic adjusted Claude Code's default reasoning effort level from high to medium. Effort level controls how much effort the model puts into a particular reasoning task. Anthropic hoped the change it made would reduce the latency that followed from longer periods of cogitation.

"This was the wrong tradeoff," the company said. "We reverted this change on April 7 after users told us they'd prefer to default to higher intelligence and opt into lower effort for simple tasks."

Presumably, turning down the default effort level on Opus 4.6 and Sonnet 4.6 would also have lightened the inference burden – models would "think" less and consume fewer tokens, using limited capacity more judiciously.

The latest Claude Code build, v2.1.118, defaults to "xhigh" on Sonnet 4.6.

Anthropic’s second misfire was a bug introduced on March 26 when a cache optimization change ended up clearing cached session data with every turn of the prompt and response cycle.

Claude caches input tokens for an hour, which benefits the user by making sequential API calls faster and cheaper. Company engineers decided they wanted to clear output tokens (thinking sessions) for users who were idle for an hour, since the cache would not be used after that much time.

Anthropic’s motive for the change was to reduce the cost of resuming a session by disposing of old thinking traces that would no longer be relevant. Instead, engineers – Claude? – introduced a bug that cleared thinking sessions with each turn. The result was that Claude became "forgetful and repetitive." This was fixed April 10 for Sonnet 4.6 and Opus 4.6.

Third, on April 16 Anthropic revised its system prompt, among other measures, in an effort to make Claude models less verbose. The added passage sounds harmless:

"Length limits: keep text between tool calls to ≤25 words. Keep final responses to ≤100 words unless the task requires more detail."

Following several weeks of internal testing, model quality evaluations suggested the change was safe. But after shipping the amended system prompt in conjunction with the release of Opus 4.7, subsequent ablation tests – which involve removing system prompt instructions to measure the effect of their absence – revealed a three percent performance drop for both Opus 4.6 and 4.7. The relevant system prompt adjustment was reverted on April 20.

Anthropic is promising it will conduct more internal tests for future public builds of Claude Code, improvements in its Code Review tool, better evaluation of system prompt changes, and a new @ClaudeDevs account on social media site X "to give us the room to explain product decisions and the reasoning behind them in depth."

This only a day after head of growth Amol Avasare took to X to explain an unannounced A/B test and said the company would try to communicate more directly, so people don't have to hear about issues through social media channels like X and Reddit.

To help customers rediscover the state of being comfortably numb, the AI reset account usage levels for everyone.

"This isn't the experience users should expect from Claude Code," the company said. ®

YouTuber has DIMM idea, builds working DRAM in backyard • The Register

Fri, 24 Apr 2026 00:22:12 +0000

If you follow PC hardware prices, you’ll know AI demand has pushed memory prices higher as manufacturers prioritize memory for datacenters. To deal with that, you can pay through the nose, buy less memory, or ... try to build your own DRAM.

Dr. Semiconductor is a YouTuber who joined the platform in February and has only published two videos so far. One shows his process of turning a backyard shed into a cleanroom tidy enough to make his own semiconductors, while the other shows him producing working sample memory cells.

Youtube Video

The YouTuber opens his second video on the making of his sample chips with an acknowledgment that the whole experiment has been driven by RAM prices skyrocketing last year and into the beginning of 2026, leading to vendor quotes that constantly fluctuate and even delays in broadband expansions caused by a lack of memory chips.

Against that backdrop is Dr. Semiconductor, whose video walks through the process inside a tiny cleanroom equipped to make DIY RAM cells.

Like any good RAM manufacturing process, Dr. Semiconductor started by designing a 5x4 array of capacitors and transistors - barely a fraction of the number of cells on a modern DRAM chip - then transferring the design onto silicon, coating it with photoresist for patterning and etching, and doping parts of the chip with phosphorus to increase conductivity. He then built up microscopic layers one by one without any of the industrial automation available to Samsung, SK hynix, or Micron.

After making a few small sample chips, Dr. Semiconductor tested them using his parameter analyzers. Some additional DIY manipulation was necessary to probe the tiny chips, as the 5x4 array is small enough that the device had to be measured with micromanipulators and extremely fine probe tips.

"Because the devices are at the nanoscale you can't just attach regular wires," the self-described doctor explained. "So for testing purposes I have a number of micromanipulators with some incredibly fine probe tips in order to feed current and voltage into the device."

The tests showed that the DIY RAM cells all functioned as expected, though higher voltage led to punch through due to the source and drain portions of each RAM cell being just a single micron apart. This "shows the trouble with scaling," according to Dr. Semiconductor, but he said it won't be a problem unless he tries to feed higher voltage into his memory.

As for the capacitors in the homemade chip, each was found to be able to hold 12.3 picofarads, which was right in line with what Dr. Semiconductor hoped to achieve, describing it as "pretty close to the perfect ideal theoretical of a little less than 15 pF I designed for."

Unfortunately, the capacitors in the DIY RAM cells in his test chip were only able to hold a charge for around 4 milliseconds - far less than commercial RAM, which he noted can retain charge for more than 64 milliseconds.

Not perfect, but for a first try at creating homemade DRAM in a backyard microfab, it's quite the start.

"This is awesome - first time ever RAM has been made at home," Dr. Semiconductor said in the video. We can't confirm that claim, but we're not aware of anyone else making RAM in their backyard shed.

That said, the fact that it's an array of just 5x4 cells means this RAM isn't going to meet any important memory metrics anytime soon.

"While you can store data on it, you can't run DOOM in it quite yet - this is just a few cells to prove it will work," Dr. Semiconductor explained. He's not done here, though. Next up is chaining a bunch of his homemade cells together to see if they can actually serve as memory for a PC.

When the results of that test might be published is unknown, but don't get too excited: Just because one enterprising individual managed to fabricate homemade RAM cells doesn't mean a cottage (or shed, to be fair) computing industry is likely to pop up overnight.

AI memory demand may become more efficient, and there may be early signs of pricing pressure easing, but the shortage is unlikely to end anytime soon. Buckle up, or consider building your own fab. ®

Anthropic Mythos model can find and exploit 0-days • The Register

Thu, 23 Apr 2026 11:13:49 +0000

For years, the infosec community’s biggest existential worry has been quantum computers blowing away all classical encryption and revealing the world’s secrets. Now they have a new Big Bad: an AI model that can generate zero-day vulnerabilities.

Anthropic made the model and named it Mythos. Thankfully, the AI company decided not to release it, because it would break the internet – and not in a good way.

"AI models have reached a level of coding capability where they can surpass all but the most skilled humans at finding and exploiting software vulnerabilities," the company said.

Mythos is markedly different from Claude Opus 4.6, which Anthropic only recently said was not very skilled at developing working exploit code. Where Opus 4.6 managed an exploit development success rate of just over zero percent, Mythos Preview generated a working exploit 72.4 percent of the time.

What Anthropic is describing is literally a zero-day engine: "Engineers at Anthropic with no formal security training have asked Mythos Preview to find remote code execution vulnerabilities overnight, and woken up the following morning to a complete, working exploit."

Fortunately, instead of releasing Mythos, Anthropic chose to provide a preview version to a set of industry partners so they can use it to find flaws in their systems before adversaries do.

The AI biz calls its limited release initiative Project Glasswing. Participants include: Amazon Web Services, Anthropic, Apple, Broadcom, Cisco, CrowdStrike, Google, JPMorganChase, the Linux Foundation, Microsoft, NVIDIA, and Palo Alto Networks.

And while this tech industry anti-rogues’ gallery scans their own systems with the purportedly perspicacious Mythos, Anthropic invited around 40 other organizations to participate in this introspective bug hunt, subsidized by up to $100M in usage credits for Mythos Preview and $4M in direct donations to open-source security organizations.

If that sounds a bit like an arsonist handing out fire extinguishers, well, that's on you for being so cynical.

Word of Mythos leaked last month when a draft blog post from Anthropic surfaced. The details published on Tuesday paint a stark picture for the security community: "During our testing, we found that Mythos Preview is capable of identifying and then exploiting zero-day vulnerabilities in every major operating system and every major web browser when directed by a user to do so."

The 22 Anthropic researchers listed as authors of its Tuesday post insist that the vulns are often subtle and difficult to detect. Some are decades old, like the now-patched 27-year-old bug in OpenBSD.

"The exploits it constructs are not just run-of-the-mill stack-smashing exploits (though as we'll show, it can do those too). In one case, Mythos Preview wrote a web browser exploit that chained together four vulnerabilities, writing a complex JIT heap spray that escaped both renderer and OS sandboxes. It autonomously obtained local privilege escalation exploits on Linux and other operating systems by exploiting subtle race conditions and KASLR-bypasses. And it autonomously wrote a remote code execution exploit on FreeBSD's NFS server that granted full root access to unauthenticated users by splitting a 20-gadget ROP chain over multiple packets."

According to Anthropic, Mythos identified "thousands of additional high- and critical-severity vulnerabilities." The company is in the process of disclosing them responsibly.

Uh, thanks? ®

AI agent hacked McKinsey chatbot for read-write access • The Register

Thu, 23 Apr 2026 10:21:02 +0000

Researchers at red-team security startup CodeWall say their AI agent hacked McKinsey's internal AI platform and gained full read and write access to the chatbot in just two hours.

It's yet another indicator that agentic AI is becoming a more effective tool for conducting cyberattacks, including those against other AI systems.

This attack wasn’t conducted with malicious intent. However, threat hunters tell us that miscreants are increasingly using agents in real-world attacks, indicating that machine-speed intrusions aren't going away.

McKinsey, a mega-management consultancy that specializes in gnarly strategy work for huge corporations and governments, rolled out its generative AI platform called Lilli in July 2023. According to the company, 72 percent of its employees – that's upwards of 40,000 people – now use the chatbot, which processes more than 500,000 prompts every month.

CodeWall uses AI agents to continuously attack customers' infrastructure, to help them improve their security posture. According to the startup, its own security agent suggested targeting McKinsey, citing the consulting company's public responsible disclosure policy and recent updates to Lilli.

"So we decided to point our autonomous offensive agent at it," the researchers wrote in a Monday blog, noting that the agent didn't have access to any credentials for McKinsey’s assets.

CodeWall’s researchers claim that within two hours of starting their red team raid, they achieved full read and write access to the entire production database and were able to access 46.5 million chat messages about strategy, mergers and acquisitions, and client engagements, all in plaintext, along with 728,000 files containing confidential client data, 57,000 user accounts, and 95 system prompts controlling the AI's behavior. These prompts were all writable, meaning an attacker could poison everything Lilli spits out to all of the tens of thousands of consultants using the chatbot.

CodeWall's agent found the SQL injection flaw at the end of February, and the researchers disclosed the full attack chain on March 1. By the following day, McKinsey had patched all unauthenticated endpoints, taken the development environment offline, and blocked public API documentation.

A McKinsey spokesperson told The Register that it fixed all of the issues identified by CodeWall within hours of learning about the problems.

"Our investigation, supported by a leading third-party forensics firm, identified no evidence that client data or client confidential information were accessed by this researcher or any other unauthorized third party," the spokesperson told us. "McKinsey's cybersecurity systems are robust, and we have no higher priority than the protection of client data and information we have been entrusted with."

AI vs AI

CodeWall CEO Paul Price declined to tell us the exact prompts his team used to exploit the chatbot, but said the entire process was "fully autonomous from researching the target, analyzing, attacking, and reporting."

The CodeWall agent initially gained access to Lilli after finding publicly exposed API documentation, including 22 endpoints that didn't require authentication. One of these wrote user search queries, and the agent found that the JSON keys (these are the field names) were concatenated into SQL and vulnerable to SQL injection.

"When it found JSON keys reflected verbatim in database error messages, it recognised a SQL injection that standard tools wouldn't flag," the researchers wrote, adding that the error messages eventually began outputting live production data.

It gets worse: Lilli's system prompts were stored in the same database, which gave the agent access to these as well.

Because the SQL injection flaw was read and write, an attacker could abuse this to silently rewrite Lilli's prompts, thus poisoning how the chatbot answered consultants' queries, what guardrails it followed, and how it cited sources. "No deployment needed," the blog says. "No code change. Just a single UPDATE statement wrapped in a single HTTP call."

These security holes are now closed – but the larger threat remains, Price told The Register.

"We used a specific AI research agent to autonomously select the target, it did this without zero human input," he said. "Hackers will be using the same technology and strategies to attack indiscriminately, with a specific objective in mind," such as "financial blackmail for data loss or ransomware." ®

Manage attack infrastructure? AI agents can now help • The Register

Thu, 23 Apr 2026 10:21:02 +0000

interview AI agents allow cybercriminals and nation-state hackers to outsource the "janitorial-type work" needed to plan and carry out cyberattacks, according to Sherrod DeGrippo, Microsoft's GM of global threat intelligence. North Korea is taking advantage.

This includes tasks such as performing reconnaissance on compromised computers, and standing up and managing attack infrastructure - which may not sound as thrilling as plotting and carrying out digital intrusions, but are real-world criminal use cases for agentic AI that should make threat hunters sit up and take notice.

"Agentic, automated reconnaissance against systems is something that is worth taking a look at," DeGrippo said during an interview with The Register. "Go find out about XYZ, and come back to me with everything you've seen. Go scan the net blocks owned by this particular entity."

An attacker could do this manually, but it would take a lot more time than asking an agent to do it for them. It's "a great example of AI that can be used for regular, standard business purposes and can also be used by threat actors for malicious purposes," she said.

In a Friday blog, Microsoft says that this is one of the ways miscreants are using AI to improve the efficiency and productivity of their criminal operations, resulting in attacks that are better, bigger, and faster.

Infrastructure management is another area where AI agents come in handy, DeGrippo said. "We have always seen threat actors stand up the infrastructure, whether that means compromising existing legitimate infrastructure and using it for malicious purposes, or purchasing accounts and setting up their own infrastructure to launch threat campaigns," she said.

Microsoft Threat Intelligence has observed North Korea's Coral Sleet - one of the crews behind the fake IT worker scam - using development platforms to quickly create and manage their attack infrastructure at scale, allowing more rapid campaign staging, testing, and command-and-control operations, according to the Friday blog.

"From an agentic AI use case, this is very interesting because you can talk to your malicious infrastructure with natural language and convey your ideas just by expressing them," DeGrippo said.

Both uses save attackers time and effort, and also lower barriers for less technically savvy criminals, especially when it comes to building infrastructure that won't be detected by defenders.

"Threat actors will do what works, and they will do what gets them their objective easiest and fastest," DeGrippo said. "And so handing threat actors these really powerful tools is going to allow them to do more of that."

While Microsoft's threat intel team and other security researchers have documented attackers using agentic AI to generate malware, agents' code-writing skills can't yet rival those of humans, DeGrippo told us. But, she added, there are two parts to this use case.

"When we detect AI-generated or AI-enabled malware, traditionally, we have noticed that it's different from regular malware," she said. "It does have those hallmarks that when a human looks at the code, they can say, 'I think this was AI generated.'"

The second part, which involves malware that can call different AI functions and libraries, is the more interesting use, "and more sophisticated," according to DeGrippo.

"Anybody who has a software development background, regardless of if they're developing benign software or malicious software, is thinking about how to better enhance their workflows with AI," she said. "It doesn't matter if you're building the next SaaS CRM application, a phone app to manage your kids' soccer games, or malware that's intended to steal money or do espionage. Anyone developing any kind of code is thinking about how to use an AI assistant to do that." ®

AWS would prefer to forget March in UAE region • The Register

Wed, 22 Apr 2026 21:15:02 +0000

I received an email / billing notification from AWS this week that may be the most diplomatically crafted communication in the history of cloud computing. Here it is, stripped of the usual boilerplate around it:

"AWS is waiving all usage-related charges in the ME-CENTRAL-1 Region for March 2026. This waiver applies automatically to your account(s), and no action is required from you."

No explanation. No mention of the Iranian drone strikes that physically destroyed two of three availability zones in the region on March 1st. No reference to the 109 services that went down, nor the customers who spent weeks unable to terminate EC2 instances via the console because the control plane was as dead as the hardware underneath it. No acknowledgment that an entire month of cloud infrastructure effectively ceased to exist. Not even a link to their remarkably short (presumably because it wasn't insulting the Financial Times' reporting) corporate blog post explaining that you probably shouldn't expect that region to be working reliably again any time soon.

Just: we're waiving the charges. You're welcome. Move along.

I want to be clear: I have no problem with this. It's a tough situation, and it's not AWS' fault, given that there is not yet an Amazon standing military force.

But here's the part that caught my attention. The email continues: "You will not see any March 2026 usage for the ME-CENTRAL-1 Region in your Cost and Usage Report or Cost Explorer once processing is complete."

They're not just waiving customer charges for a month; they're erasing the billing and inventory data!

The bill is the only inventory you've got

For most organizations, the AWS bill isn't just an invoice. It's the canonical record of what infrastructure exists, where it's running, and how long it's been there. The Cost and Usage Report (CUR) is the closest thing many companies have to a single source of truth that accurately describes their cloud footprint. Even the relatively-recently-launched AWS Resource Explorer, which purports to be an inventory service, is missing some key resource types. The one thing that lists everything remains the AWS bill; a single source of truth around what the hell's living in your cloud environment.

Compliance teams rely on it. Auditors request it. FinOps teams build their entire practice on it. When your security team wants to know if you had resources running in the Middle East in March beyond what CloudTrail says, they'll check the CUR. And as of March 31st, when they ask Amazon’s answer will be: No. You didn't. Nothing was there. A clean, empty month.

The infrastructure existed, kinda. It ran, or at least it sure tried to. Customers were billed for resources they couldn't turn off because the API was unreachable, because nothing works properly when you have two of three availability zones non-responsive or flat out destroyed. And now the record of all of that is being zeroed out.

In fairness, nobody plans for this

Before anyone starts composing their "AWS should have been prepared for this" hot take: No. Stop.

AWS engineers availability zones for certain classes of failure. Hardware dies, power goes out, a fiber gets cut by its natural predator "The Mighty Backhoe," a cooling system fails, or the like? AZs handle these. They're designed so that a problem in one zone doesn't cascade to another. That model works. It's been tested repeatedly. It's the backbone of every well-architected deployment on AWS. Know it or not, virtually every AWS customer's data recovery strategy depends upon this being true.

AZs are not designed for a state actor deciding the data center shouldn't exist anymore.

Nobody's fault-tree analysis includes "building hit by military drone." No disaster recovery runbook in the world has a section titled "Regional Armed Conflict."

And honestly? It shouldn't. Try putting that into your company data recovery plan, and you'll get uninvited from business continuity planning faster than I was at investment firm BlackRock when I pointed out that if both San Francisco and us-east-1 were unavailable, absolutely nobody was going to care about our roboadvisor for the foreseeable future, if ever. (I can't imagine why I was let go from that job.) The entire premise of cloud infrastructure is that you're renting capacity from someone who handles the physical concerns so you can focus on your software. That contract didn't account for the data center becoming a military target, and it's hard to blame anyone this side of the Pentagon for not having that particular item on the risk register.

So why erase the data?

I can think of two explanations, and they're not mutually exclusive.

First, the data might not exist to provide. When multiple AZs go offline because the physical hardware is melted and TLS now terminates "on the floor," the metering and billing infrastructure goes with it. You can't generate a usage report for resources running on servers that no longer have power, or physical cohesion. AWS may genuinely not have reliable telemetry for what was running, what stopped, and when. You can't charge for what you can't measure – and you can't report what you didn't record.

Second, pragmatism. Customers couldn't terminate resources with the AWS console because termination commands require acknowledgement; they're not hurled over the fence like a dead dog for your neighbor to worry about. EC2 instances were stuck in stopped states for weeks. Elastic IPs were trapped on dead hardware. If AWS had tried to bill normally and then process refunds, it would have meant thousands upon thousands of individual support tickets, each one a paper trail documenting precisely what failed and when. Life would have become absolute hell for the hardworking folks at AWS Support. A blanket waiver with a clean data slate is operationally simpler and diplomatically tidier in a single move.

I suspect it's both.

The precedent is the point

Whatever the underlying reason, AWS made the right call. Customers shouldn't pay for resources they couldn't control in a region that was physically destroyed by military action. The waiver is the correct outcome.

But.

The mechanism now exists, and it's been exercised. AWS can zero out an entire month of usage data across a region, and the result is indistinguishable from that month never happening. The bill, the one canonical source of truth, simply won't show it.

Today the reason is a war, and it's a good reason. But precedents don't come with permanent context attached. The next time a month of data goes missing from CUR, will there be an email? Will there be an explanation? Will there be a *reason* you'd accept?

I don't know. AWS isn't saying. They probably can't say much. And after March 31st, the data won't be saying anything either.

Meta staff protest surveillance software on work PCs • The Register

Wed, 22 Apr 2026 12:47:29 +0000

Meta, the company built on watching everything its billions of users do online so it can keep them clicking on ragebait and targeted ads, is reportedly now installing surveillance software on employees’ work computers.

Newswire Reuters reports that Meta management sent staff a memo informing them that they’ll soon run a new tool called “Model Capability Initiative” that will record their keystrokes, mouse movements, and even take occasional screenshots – all in the name of gathering data the social networking giant can use to build better AI models.

Business Insider claims it’s got the memo, which apparently says surveillance will observe workers as they use “work-related applications and URLs” including Gmail, GChat, VCCode, and an internal app called “Metamate”.

The document reportedly explains that Meta feels AI models don’t understand how people use computers, so the company needs real-life examples of how meatbags click their way through a working day so it can build agents. CTO Andrew Bosworth apparently said collecting this data from Meta staff will help the company to realize a vision for a world “where our agents primarily do the work and our role is to direct, review and help them improve.”

Meta is not alone in pursuing such a vision: Anthropic debuted tech capable of doing this in 2024 and OpenAI last year announced “Operator” – a tool that can use a web browser on a human’s behalf.

Microsoft has even created a special type of cloud PC for agents to use.

All imagine that in the not-too-distant future many of us will designate some tasks that we currently undertake with our own brains and fingers on a physical PC to an agent that uses a virtual PC. AI folk imagine asking an agent to book an airfare, respond to email, or constantly scan e-tail sites to spot a discount for a desired item and then swoop in to make a purchase.

Meta’s term for this sort of thing is a “personal superintelligence” that CEO-for-life Mark Zuckerberg says “helps you achieve your goals, create what you want to see in the world, experience any adventure, be a better friend to those you care about, and grow to become the person you aspire to be.”

So long as your goals and aspirations don’t include workplace privacy.

This situation is replete with irony, given Meta has for years mined its users for information and often run afoul of privacy laws.

Now the company’s remaining staff can get a taste of the unease users have felt for years. ®

AI-authored code needs more attention, contains worse bugs • The Register

Wed, 22 Apr 2026 09:02:30 +0000

Generating code using AI increases the number of issues that need to be reviewed and the severity of those issues.

CodeRabbit, an AI-based code review platform, made that determination by looking at 470 open source pull requests for its State of AI vs Human Code Generation report.

The report finds that AI-generated code contains significantly more defects of logic, maintainability, security, and performance than code created by people.

On average, AI-generated pull requests (PRs) include about 10.83 issues each, compared with 6.45 issues in human-generated PRs. That's about 1.7x more when AI is involved, meaning longer code reviews and increased risk of defects.

Problems caused by AI-generated PRs also tend to be more severe than human-made messes. AI-authored PRs contain 1.4x more critical issues and 1.7x more major issues on average than human-written PRs, the report says.

Machine-generated code therefore seems to require reviewers to deal with a large volume of issues that are more severe than those present in human-generated code.

These findings echo a report issued last month by Cortex, maker of an AI developer portal. The company's Engineering in the Age of AI: 2026 Benchmark Report [PDF] found that PRs per author increased 20 percent year-over-year even as incidents per pull request increased by 23.5 percent, and change failure rates rose around 30 percent.

The CodeRabbit report found that AI-generated code falls short of meatbag-made code across the major issue categories. The bots created more logic and correctness errors (1.75x), more code quality and maintainability errors (1.64x), more security findings (1.57x), and more performance issues (1.42x).

In terms of specific security concerns, AI-generated code was 1.88x more likely to introduce improper password handling, 1.91x more likely to make insecure object references, 2.74x more likely to add XSS vulnerabilities, and 1.82x more likely to implement insecure deserialization than human devs.

One area where AI outshone people was spelling – spelling errors were 1.76x more common in human PRs than machine-generated ones. Also, human-authored code had 1.32x more testability issues than AI stuff.

"These findings reinforce what many engineering teams have sensed throughout 2025," said David Loker, director of AI at CodeRabbit, in a statement. "AI coding tools dramatically increase output, but they also introduce predictable, measurable weaknesses that organizations must actively mitigate."

CodeRabbit cautions that its methodology has limitations, such as its inability to be certain that PRs labeled as human-authored actually were exclusively authored by humans.

Other studies based on different data have come to different conclusions.

For example, an August 2025 paper by University of Naples researchers, "Human-Written vs. AI-Generated Code: A Large-Scale Study of Defects, Vulnerabilities, and Complexity," found that AI-generated Python and Java code "is generally simpler and more repetitive, yet more prone to unused constructs and hardcoded debugging, while human-written code exhibits greater structural complexity and a higher concentration of maintainability issues."

Back in January 2025, researchers from Monash University (Australia) and University of Otago (New Zealand) published a paper titled "Comparing Human and LLM Generated Code: The Jury is Still Out!"

"Our results show that although GPT-4 is capable of producing coding solutions, it frequently produces more complex code that may need more reworking to ensure maintainability," the southern hemisphere boffins wrote. "On the contrary, however, our outcomes show that a higher number of test cases passed for code generated by GPT-4 across a range of tasks than code that was generated by humans."

As to the impact of AI tools on developer productivity, researchers from Model Evaluation & Threat Research (METR) reported in July that "AI tooling slowed developers down."

Your mileage may vary.

We note that Microsoft patched 1,139 CVEs in 2025, according to Trend Micro researcher Dustin Childs, who claims that's the second-largest year for CVEs by volume after 2020.

Microsoft says 30 percent of code in certain repos was written by AI and Copilot Actions comes with a caution about "the security implications of enabling an agent on your computer."

"As Microsoft's portfolio continues to increase and as AI bugs become more prevalent, this number is likely to go higher in 2026," Childs wrote in his post.

But at least we can expect fewer typos in code comments. ®

UK's corporate registry fixes data exposing technical error • The Register

Sat, 18 Apr 2026 23:18:57 +0000

Companies House was forced to pull down its record-filing platform for the entire weekend to rectify a "security issue" that exposed the personal details of company directors and other data to any logged in users.

The government agency, which manages the UK's register of all businesses and their directors, temporarily shut down its WebFiling service on March 13 at 13.30 UTC following reports that hidden company details could be seen and modified.

In a statement, it confirmed techies resolved the flaw on and WebFiling was online again from 09.00 today.

While the mishap allowed directors to read and change hidden data belonging to other companies, in theory any individual could have created a company on the platform and abused the flaw.

"Our investigation has established that specific data from individual companies not normally published on the Companies House register may have been visible to other logged-in WebFiling users," Companies House CEO Andy King said on Monday.

"This includes dates of birth, residential addresses, and company email addresses. It may also have been possible for unauthorized filings – such as accounts or changes of director – to have been made on another company's record."

King said passwords were not among the types of data accessible by other users, nor were documents related to identity verification, such as passports. "No existing filed documents, such as accounts or confirmation statements could have been altered.

"We believe that this issue could not have been used to extract data in large volumes or to access records systematically," he added. "Any access would have been limited to individual company records, viewed one at a time by a registered WebFiling user."

An internal investigation revealed that changes made to the WebFiling platform in October 2025 introduced the unexpected behavior, but attention was first drawn to it on March 13 by tax professional Dan Neidle.

The founder of Tax Policy Associates published a video on social media depicting how the flaw could be abused to access other companies' data.

Neidle said he was made aware of the flaw by John Hewitt, director of operations at Ghost Mail, and he then informed Companies House immediately.

Now fixed, a logged-in company director could exploit the flaw by starting from their own dashboard and then trying to log into another company's account.

Once they reach the 2FA block, which they would not be able to pass, all that was required was to click the browser's back button a few times. Typically, the user would be taken back to their own dashboard, but the bug instead returned them to the company they had tried to log into but couldn't.

Companies House said it reported the incident to the Information Commissioner's Office and National Cyber Security Centre, and continues to investigate whether the flaw was abused for real since October.

"If we find evidence that anyone has used this issue to access or change another company's details without authorization, we will take firm action," said King.

"I recognize that this incident will have caused concern and inconvenience to many of the companies and individuals who rely on our services. I am sorry for that.

"Companies House takes its responsibility to protect the data entrusted to us extremely seriously. We have taken swift action to secure and restore our service, and are committed to doing everything in our power to support those affected and to make sure that our services continue to merit the trust placed in them." ®

Claude Opus wrote a Chrome exploit for $2,283 • The Register

Sat, 18 Apr 2026 11:45:45 +0000

Anthropic withheld its Mythos bug-finding model from public release due to concerns that it would enable attackers to find and exploit vulnerabilities before anyone could react.

But the company's Opus 4.6 model, already superseded by the release of Opus 4.7 on Thursday, is capable of developing functional exploit code.

In a blog post on Wednesday, Mohan Pedhapati (s1r1us), CTO of Hacktron, described how he used Opus 4.6 to create a full exploit chain targeting the V8 JavaScript engine in Chrome 138, which is bundled into current versions of Discord.

"The V8 [out of bounds error] we used was from Chrome 146, the same version Anthropic's own Claude Desktop is running," he said. "A week of back and forth, 2.3 billion tokens, $2,283 in API costs, and about ~20 hours of me unsticking it from dead ends. It popped calc."

Eventually, any script kiddie with enough patience and an API key will be able to pop shells

“Popped calc” is a reference to opening the calculator app – an event commonly used in proof-of-concept exploit code to indicate that an attack compromised the target system.

Pedhapati said that while $2,283 is a significant sum for an individual to pay, it's very little if you consider the weeks it would take a person to develop a similar exploit without assistance. Even if you added several thousand dollars for Pedhapati's time tending the model, that's still significantly less the theoretical reward (~$15,000) one might get from Google's and Discord's vulnerability reward programs. And that's just the legitimate market – who knows what criminals might pay for a hot 0-day?.

According to the Opus 4.7 System Card, "Opus 4.7 is roughly similar to Opus 4.6 in cyber capabilities." But it's apparently less capable than Mythos Preview and comes with "safeguards that automatically detect and block requests that indicate prohibited or high-risk cybersecurity uses."

But for Pedhapati, the specific model isn't the issue. Rather, it's ongoing improvements in code generation that demand a change of security posture and procedure.

"Whether Mythos is overhyped or not doesn't matter," said Pedhapati. "The curve isn't flattening. If not Mythos, then the next version, or the one after that. Eventually, any script kiddie with enough patience and an API key will be able to pop shells on unpatched software. It's a question of when, not if."

For apps based on the Chrome-based Electron framework (e.g. Slack, Discord, etc.) the question is when will they update their codebase to the latest version, which is still behind the latest Google Chrome release.

Electron 41.2.1, released on April 15, bundles Chrome 146.0.7680.188, just one version behind the desktop Google Chrome version (147.0.7727.101/102) released that day. But developers of Electron apps don't necessarily update their dependencies and issue new versions immediately. And users don't necessarily get those updates immediately.

Pedhapati said he picked Discord as a target because "It's sitting on Chrome 138, nine major versions behind current."

Pedhapati argues that as AI models become more capable of exploit development, the patch window gets smaller.

"Every patch is basically an exploit hint," he argues, adding that this will be particularly difficult for open source projects, because fixes often become publicly visible in code before the revised version gets released.

His advice to developers is to focus more on security before code gets pushed and to pay closer attention to dependencies, so changes can be made quickly. He also argues that security patches should be done automatically, so people aren't left vulnerable because they forgot to accept an update. And he says open source projects like V8 use more caution in terms of when the public vulnerability details.

"Every public commit is a starting gun for anyone with an API key and strong team members who can weaponize exploits," he said. ®

Claude devs complain about surprise usage limits • The Register

Sat, 18 Apr 2026 10:14:59 +0000

Software developers who use Anthropic's Claude Code have been sounding the alarm for the past few days about changes in the AI service's usage limits.

Some customers have objected to the rapid consumption of their token allotment in the company's Discord channel, and they claim that their criticism has been silenced by channel moderators.

Anthropic insists the issue follows from the expiration of a holiday usage bonus and that the company doesn't try to limit discussion of usage limits – the implication being that any Discord bans follow from community policy violations.

An Anthropic customer and forum user who asked not to be identified provided The Register with screenshots of various Discord interactions and offered his assessment of the issue. He claims that there's been a roughly 60 percent reduction in token usage limits, based on a token-level analysis of Claude Code logs. He speculates that the changes represent an attempt to reduce costs prior to Anthropic's expected public stock offering, a claim Anthropic flatly denies.

Evidence of concern among developers using Claude Code and other Claude services has surfaced on Reddit, where a recent post claims "Claude usage consumption has suddenly become unreasonable."

Numerous participants in that discussion argue that model interactions now consume more tokens than they did previously, which results in the account usage limits being reached sooner.

Other Reddit threads raise similar concerns. The Claude Developers Discord channel also includes a post from a developer claiming to have run out of token capacity on an enterprise account.

A current thread posted by "David," an admin for Anthropic's Claude Developers Discord channel, asks forum participants to post their rate limit concerns, promising an investigation into reports of inconsistent usage limits.

Forum participant "A A Ron" responded:

I limited out very fast this morning w/out even writing code - just reviewing markdown specs. Felt very unusual - came here to see if others were reporting. I can't submit my account info to the PM request you posted as I don't have permission. Unfortunately my analytics in the console are all blank – which makes it really hard to validate whether this is on my end or not. Max plan user and historically I would only limit out occasionally – this am it was within an hour with very light (weekend slow review of a few docs) usage.

Others echo those remarks. A separate post in the #claude-code-lounge channel this morning begins, "I am a Claude Pro/Max subscriber experiencing severely restrictive usage limits that make the service unusable for development work. Despite having an active Pro plan, I consistently hit usage limits within 10–15 minutes of using Sonnet, with the usage bar showing near 100 percent consumption. Opus is even more limited, often becoming unavailable shortly after starting."

It's worth noting that complaints about token usage limits have been around for many months. A mega-thread in the Discord channel dating back to October 9, 2025, offers a record of the discontent.

Anthropic offers three individual subscription plans: Free, Pro ($20/month), and Max ($100 or $200 per month), each with its own usage limits. The Pro plan promises 5x the usage allowed for the Free plan; the Max plan promises either 5x or 20x the usage of the Pro plan.

There are also two business subscription plans – Team ($25/$150 per seat/month) and Enterprise (not publicly disclosed but said to be $60 per seat with a minimum of 70 seats per month). Team usage is "more" than the Pro plan. Enterprise limits aren't specified.

The Register spoke with an Anthropic representative who dismissed the claims about usage reductions as unfounded and suggested customers are simply reacting to the withdrawal of bonus usage awarded over the holidays.

During the period from December 25 through December 31, 2025, Anthropic doubled the customer usage limits of Claude models as a holiday gift. This was done, we're told, to make use of idle compute capacity during that period, the result of vacationing enterprise customers.

Our source claims that removal of those higher limits has reduced usage allowances below their original baseline, but Anthropic says that's incorrect. The concerns being raised, we're told, appear to be largely a response to the resumption of normal limits.

One of the Reddit threads includes the suggestion that the heightened consumption of tokens follows from a Claude Code bug, detailed in a GitHub Issues post. Some users report that rolling Claude Code back to version 2.0.61 fixed the issue; others disagree.

Anthropic's representative said that its team takes all such reports seriously but hasn't identified any flaw related to token usage. Last month, Anthropic looked into reports of problems with its Claude Opus 4.5 model and said it had ruled out bugs in its inference stack.

Nonetheless, a bug report filed on Sunday, January 4, 2026, suggests there's something amiss with the reversion of the pre-holiday usage limits. ®

FBI confirms Zodiac Killer's 340 cipher solved by trio of amateur math and software codebreakers • The Register

Fri, 17 Apr 2026 20:06:05 +0000

A team of code breakers has solved a cipher attributed to the Zodiac Killer, a serial murderer known for a Northern California killing spree in the late 1960s who has still not been identified or apprehended.

David Oranchak, a US-based software developer, Sam Blake, a mathematician based in Australia, and Jarl Van Eycke, a programmer based in Belgium, managed to crack Z340, a 340-character cipher that's one of four such codes attributed to the Zodiac Killer.

Z340 was sent to The San Francisco Chronicle on November 8, 1969, and was provided to the FBI shortly thereafter. It remained unsolved for 51 years until Saturday, December 5th, 2020, when Oranchak, Blake, and Van Eycke submitted their solution to the US Federal Bureau of Investigation and had their solution validated.

In a statement distributed via Twitter on Friday, the FBI confirmed the cipher had indeed been undone.

"The FBI is aware that a cipher attributed to the Zodiac Killer was recently solved by private citizens," the agency said, noting that the case remains an ongoing investigation for the FBI's San Francisco division and that it would provide no further comment out of respect for the Zodiac's victims.

In a video posted to YouTube, Oranchak explains how the trio worked together, using an app created by Van Eycke called AZdecrypt, to break the code.

"Sam [Blake] became interested in ways to do transpositions or manipulations of the 340," Oranchak said. "It was assumed that Zodiac did something different to the message before assigning all the symbols and that could explain why the cipher was unsolved for so long. So we started doing a lot of experiments."

Watch: Rare Second World War footage of Bletchley Park-linked MI6 intelligence heroes emerges, shared online

Blake, he said, created 650,000 variations of the ciphertext, arranged in different ways. The idea was that if Zodiac had rearranged the order of the symbols, these variations might prove helpful to figure out how the 63 unique symbols had been scrambled.

"I took all of Sam's manipulations and ran them through Jarl [Van Eycke's] AZdecrypt code breaking program," Oranchak said. "The idea was to take Sam's hundreds of thousands of variations of the 340 and try to get AZdecrypt to crack them. Maybe we'd stumble on something."

On Thursday, December 3, 2020, the gibberish started making sense and the team finally managed to determine the order in which the symbols had to be read to retrieve a coherent message.

Click to enlarge

I HOPE YOU ARE HAVING LOTS OF FUN IN TRYING TO CATCH ME THAT WASNT ME ON THE TV SHOW WHICH BRINGS UP A POINT ABOUT ME I AM NOT AFRAID OF THE GAS CHAMBER BECAUSE IT WILL SEND ME TO PARADICE ALL THE SOONER BECAUSE I NOW HAVE ENOUGH SLAVES TO WORK FOR ME WHERE EVERYONE ELSE HAS NOTHING WHEN THEY REACH PARADICE SO THEY ARE AFRAID OF DEATH I AM NOT AFRAID BECAUSE I KNOW THAT MY NEW LIFE IS LIFE WILL BE AN EASY ONE IN PARADICE DEATH

Oranchak said as the cipher's secrets began to emerge, the references in the message to the TV show and the gas chamber convinced him that he was on the right track. As he notes in his video, the cipher was received about two weeks after someone claiming to be Zodiac had called into The Jim Dunbar Show, broadcast in the San Francisco Bay Area during that period.

The caller, Oranchak recalled, said he was sick and didn't want to go to the gas chamber. Though the caller was ruled out as a suspect, the historical reference convinced Oranchak that the cipher's message was consistent with the time it is believed to have been written.

"So it's been a very exciting few days," Oranchak concludes. "Fifty-one years after it was sent, Zodiac's 340 character cipher has finally been solved. The message doesn't really say a whole lot. It's more of the same attention seeking junk from Zodiac." ®

AI agents can't pull off fully autonomous cyberattacks – yet • The Register

Thu, 16 Apr 2026 09:31:21 +0000

AI agents and other systems can't yet conduct cyberattacks fully on their own – but they can help criminals in many stages of the attack chain, according to the International AI Safety report.

The second annual report, chaired by the Canadian computer scientist Yoshua Bengio and authored by more than 100 experts across 30 countries, found that over the past year, developers of AI systems have vastly improved their ability to help automate and perpetrate cyberattacks.

Perhaps the best, and scariest, evidence of that finding appeared in Anthropic's November 2025 report about Chinese cyberspies abusing its Claude Code AI tool to automate most elements of attacks directed at around 30 high-profile companies and government organizations. Those attacks succeeded in "a small number of cases."

"At least one real-world incident has involved the use of semi-autonomous cyber capabilities, with humans intervening only at critical decision points," according to the AI safety report. "Fully autonomous end-to-end attacks, however, have not been reported."

Two areas where AI is especially useful to criminals are scanning for software vulnerabilities and writing malicious code.

During DARPA's AI Cyber Challenge (AIxCC) – a two-year competition in which teams built AI models to find vulnerabilities in open source software that undergirds critical infrastructure – finalist systems autonomously identified 77 percent of the synthetic vulnerabilities used in the final scoring round, according to competition organizers.

And while that is an example of defenders using AI to find and fix vulnerabilities, rather than attackers using AI to find and exploit them, criminals are using models in similar ways. Last northern summer, we saw attackers on underground forums claiming to use HexStrike AI, an open-source red-teaming tool, to target critical vulnerabilities in Citrix NetScaler appliances within hours of the vendor disclosing the problems.

Additionally, AI systems are getting much better at malware writing, and criminals can trade weaponized models that write ransomware and data-stealing code for as little as $50 a month.

The good news for now, according to the report’s authors, is that AI systems still aren't great at carrying out multi-stage attacks without human help.

"Research suggests that autonomous attacks remain limited because AI systems cannot reliably execute long, multi-stage attack sequences," according to the report. "For example, failures they exhibit include executing irrelevant commands, losing track of operational state, and failing to recover from simple errors without human intervention."

Keep in mind, however, that this all was written before the security dumpster fire that is OpenClaw – the AI agent previously known as Moltbot and Clawdbot – and Moltbook, the vibe-coded social media platform for AI agents.

So it's also entirely plausible that the world won't end with a sophisticated, autonomous multi-stage cyberattack dreamed up by a nation-state crew or criminal mastermind, but rather a single agent that goes off the rails. ®

EFF: California 3D printer bill threatens digital freedoms • The Register

Tue, 14 Apr 2026 23:21:41 +0000

California's proposed legislation to put the burden of blocking 3D-printed firearms onto printer manufacturers could effectively sideline open source tools and create new surveillance concerns, digital rights activists argue.

Advocates at the Electronic Frontier Foundation (EFF) say that such legislation could empower manufacturers to introduce restrictive policies affecting consumer choice. It could lead to widespread surveillance of users' printing activity, which they fear could lead to copyright lawsuits, if that data were shared with other companies looking to protect against 3D-printed spare parts, for example.

The bill in question is AB 2047, the scope of which, on paper, appears strict. The primary goal is clear and simple: to require 3D printer manufacturers to use a state-certified algorithm that checks digital design files for firearm components and blocks print jobs that would produce prohibited parts.

Federal law does not impose a blanket ban on making firearms for personal use, though ghost guns are subject to various federal and state restrictions, and the practice remains controversial nationwide.

Gun crime rates in the US far outweigh those in all other developed countries, so introducing legislation to curb the easy manufacture of untraceable firearms will be seen as a positive initiative to many, particularly in regions where guns are more strictly regulated.

However, Cliff Braun and Rory Mir, who respectively work in policy and tech community engagement at the EFF, claim that the proposals in California are technically infeasible and in practice will lead to consumer surveillance.

In a series of blog posts published this month, the pair argued that print-blocking technology - proposals for which have also surfaced in states including New York and Washington - cannot work for a range of technical reasons.

They argued that because 3D printers and other types of computer numerical control (CNC) machines are fairly simple, with much of their brains coming from the computer-aided manufacturing (CAM) software – or slicer software – to which they are linked, the bill would establish legal and illegal software. Proprietary software will likely become the de facto option, leaving open source alternatives to rot.

"Under these proposed laws, manufacturers of consumer 3D printers must ensure their printers only work with their software, and implement firearm detection algorithms on either the printer itself or in a slicer software," wrote Braun earlier this month.

"These algorithms must detect firearm files using a maintained database of existing models. Vendors of printers must then verify that printers are on the allow-list maintained by the state before they can offer them for sale.

"Owners of printers will be guilty of a crime if they circumvent these intrusive scanning procedures or load alternative software, which they might do because their printer manufacturer ends support."

Braun also argued that it would be trivial for anyone who uses 3D printers to make small tweaks to either the visual models of firearms parts, or the machine instructions (G-code) generated from those models, to evade detection.

Mir further argued that the bill offers no guardrails to keep this "constantly expanding blacklist" limited to firearm-related designs.

In his view, there is a clear risk that this approach will creep into other forms of alleged unlawful activity, such as copyright infringement.

"This could look like Nintendo blocking a Pikachu toy, John Deere blocking a replacement part, or even patent trolls forcing the hand of hardware companies," wrote Mir. "Repressive regimes, here or abroad, could likewise block the printing of 'extreme' and 'obscene' symbols, or tools of resistance like popular anti-ICE community whistles."

Braun and Mir have a list of other arguments against the bill. They say the algorithms are more than likely to lead to false positives, which will prevent good-faith users from using their hardware.

Many 3D printer owners also have no interest in printing firearm components. Most simply want the freedom to print trinkets and spare parts while others use them to print various items and sell them as an income stream.

That said, Gun Owners of California also opposes the bill, arguing that it does not target criminals, only innocent consumers and businesses.

"Californians deserve policies that focus on criminal misuse – not sweeping mandates that expand bureaucracy and restrict lawful activity," it wrote in a response to the bill's introduction in February.

Addressing the community behind 3D printer manufacturer and slicer provider Prusa Research, community manager Tommy Muszynski said the company is keeping a close eye on developments.

"At Prusa, safety is obviously the highest priority," he said in a comment on Reddit. "We want everyone to have a safe experience in this hobby, but at the same time, we have always been firm believers in the 'right to repair' and the right for you to use the machine you bought however you see fit.

"We've built our community on open source principles and the idea that your printer is a tool for your own creativity, not a device that should be locked down or surveilled." ®

Devs say Apple still flouting EU's DMA six months on • The Register

Tue, 14 Apr 2026 15:54:44 +0000

Six months after EU regulators found Apple's App Store rules in breach of the Digital Markets Act (DMA), developers say Cupertino is still behaving as if compliance were optional.

The Coalition for App Fairness, a nonprofit organization of app developers and consumer groups, has accused Apple of persistent non-compliance with the DMA, warning that the company's revised App Store terms continue to impose fees which the legislation prohibits.

In an open letter addressed to European Commission President Ursula von der Leyen and senior commissioners, the coalition argues that Apple has failed to deliver "any meaningful changes or proposals" despite an April 2025 non-compliance decision that found its App Store policies illegal and harmful to both developers and consumers.

At the heart of the complaint is money. The DMA requires so-called gatekeepers to allow developers to offer and conduct transactions outside their app stores without charge. Apple, the coalition claims, is seeking to charge commissions of up to 20 percent on those very transactions.

"This is a blatant disregard for the law with the potential to vanquish years of meaningful work by the Commission," the letter states, accusing Apple of preserving the economics of its App Store while nominally claiming compliance.

Apple has said it will roll out new App Store terms in January 2026, but developers say the company has provided no clarity on what those changes will involve or whether they will actually comply with the DMA.

"We have seen this playbook before in Europe and beyond," the signatories warn, adding that they suspect any new terms will continue to impose fees that would violate the law.

The letter argues that this uncertainty is already doing damage. Six months after Apple's last App Store terms update, developers still do not know which rules will govern their businesses or what their costs will look like in the near term.

Apple's "lack of transparency in tandem with its rushed timelines," the coalition says, is freezing investment and innovation, effectively allowing the company to "exploit its gatekeeper position by holding the entire industry hostage."

The group also points to a growing transatlantic contrast that makes Europe look like the tougher regulator with the weaker results. While Apple continues to fight DMA enforcement in the EU, US courts have moved to curb its ability to extract fees from external transactions. Following litigation brought by Epic Games, developers in the US can now communicate freely with customers about pricing and offer payment options outside Apple's ecosystem without paying commission.

That raises what the coalition calls a "simple and urgent question." Why should European developers and consumers get a worse deal than their US counterparts, especially when the EU was first to pass a landmark law aimed at fixing digital markets? The letter argues that meaningful enforcement of the DMA would strengthen Europe's digital competitiveness and attract global investment, while weak enforcement risks turning the regulation into an expensive paper exercise.

"We trust the Commission will uphold the DMA," the signatories conclude, but they warn that if enforcement falls short, they will continue pressing policymakers to ensure Apple finally complies with the law as written – not as rewritten by Cupertino. ®

AI-built app on Lovable exposed 18K users, researcher claims • The Register

Tue, 14 Apr 2026 07:33:33 +0000

Vibe-coding platform Lovable has been accused of hosting apps riddled with vulnerabilities after saying users are responsible for addressing security issues flagged before publishing.

Taimur Khan, a tech entrepreneur with a background in software engineering, found 16 vulnerabilities – six of which he said were critical – in a single Lovable-hosted app that leaked more than 18,000 people's data.

He declined to name the app during the disclosure process, although it was hosted on Lovable's platform and showcased on its Discover page. The app had more than 100,000 views and around 400 upvotes at the time Khan began his probe.

The main issue, Khan said, was that all apps that are vibe-coded on Lovable's platform are shipped with their backends powered by Supabase, which handles authentication, file storage, and real-time updates through a PostgreSQL database connection.

However, when the developer – in this case AI – or the human project owner fails to explicitly implement crucial security features like Supabase's row-level security and role-based access, code will be generated that looks functional but in reality is flawed.

One example of this was a malformed authentication function. The AI that vibe-coded the Supabase backend, which uses remote procedure calls, implemented it with flawed access control logic, essentially blocking authenticated users and allowing access to unauthenticated users.

Khan said the intent was to block non-admins from accessing parts of the app, but the faulty implementation blocked all logged-in users – an error he said was repeated across multiple critical functions.

"This is backwards," said Khan. "The guard blocks the people it should allow and allows the people it should block. A classic logic inversion that a human security reviewer would catch in seconds – but an AI code generator, optimizing for 'code that works,' produced and deployed to production."

Because the app itself was a platform for creating exam questions and viewing grades, the userbase is naturally comprised of teachers and students. Some were from top US universities such as UC Berkeley and UC Davis, while there were "K-12 institutions with minors likely on the platform" as well, Khan said.

With the security flaws in place, an unauthenticated attacker could trivially access every user record, send bulk emails through the platform, delete any user account, grade student test submissions, and access organizations' admin emails, for example.

Of the 18,697 total user records exposed, 14,928 contained unique email addresses. The dataset included 4,538 student accounts – all with email addresses – 10,505 enterprise users, and 870 users whose full PII was exposed.

The security flaws here are not exclusive to apps hosted by Lovable; the issue is broader and well-told by now.

Vibe coding, Collins Dictionary's Word of the Year for 2025, promised to break down software development's steep learning curve and empower any prompt jockey to bring their app ideas to life.

However, when AI isn't generating slop bug reports in pursuit of lucrative bug bounties or catastrophically forgoing instructions, it can be found spewing glitzy-looking apps laden with vulnerabilities.

Veracode, for instance, recently found that 45 percent of AI-generated code contained security flaws, not to mention the myriad tales of woe reported by The Register in recent months.

Khan said he believes Lovable should take responsibility for the security of the apps it hosts, and was especially peeved when, after reporting his findings via company support, his ticket was reportedly closed without response.

"If Lovable is going to market itself as a platform that generates production-ready apps with authentication 'included,' it bears some responsibility for the security posture of the apps it generates and promotes," Khan said.

"You can't showcase an app to 100,000 people, host it on your own infrastructure, and then close the ticket when someone tells you it's leaking user data. At minimum, a basic security scan of showcased applications would have caught every critical finding in this report."

Lovable told The Register that the company has contacted the owner of the app in question and takes "any findings of this kind extremely seriously."

Regarding the closed ticket, Lovable CISO Igor Andriushchenko said that the company only received "a proper disclosure report" on the evening of February 26 and acted on the findings "within minutes."

"Any project built with Lovable includes a free security scan before publishing," Andriushchenko told The Register. "This scan checks for vulnerabilities and, if found, provides recommendations on actions to take to resolve before publishing.

"Ultimately, it is at the discretion of the user to implement these recommendations. In this case, that implementation did not happen.

"This project also includes code not generated by Lovable and the vulnerable database is not hosted by Lovable. We have been in contact with the creator of the app, who is now addressing the issue." ®

Claude is getting worse, according to Claude • The Register

Mon, 13 Apr 2026 23:33:32 +0000

Once the AI darling of programmers everywhere, Anthropic's Claude has been stumbling mightily, both in terms of cost and perceived quality. The service was down briefly on Monday with "a major outage," service trouble that only amplifies growing discontent from customers that even a bot can see.

The outage, which involved elevated error rates, affected Claude.ai and Claude Code from 15:31 to 16:19 UTC.

Screenshot of 4-13-26 outage - Click to enlarge

That's not all. In the past few months, Claude's answers have been getting less satisfactory, according to social media posts as well as issues filed on GitHub. This has occurred as Anthropic has had to take steps to reduce usage during peak hours to balance capacity and demand.

To get a more objective measurement, we pointed Claude itself at the Claude Code GitHub repo, filtered for open issues that mention quality, and gave it the following prompt: "Analyze and graph complaints about Claude Code quality in this repo since January 2026. Use open issues that mention quality concerns. Have these concerns increased lately?"

Anthropic's AI model concluded, "Yes, quality complaints have escalated sharply — and the data tells a pretty clear story."

Claude-generated assessment of Claude Code quality issues - Click to enlarge

We asked Claude to rerun its self-analysis on Monday and the results were similar, with the model emitting "The velocity is notable: April is already at 20+ quality issues in 13 days, putting it on pace to exceed March's 18 — which was itself a 3.5× jump over the January–February baseline."

Claude itself is not a reliable narrator, and just because someone (or some bot) has reported a concern to the Claude Code repo does not mean that the report is accurate or valid. It appears many issues are now AI-generated – a widely reported concern among open source developers – which may be contributing to report volume.

Anthropic's GitHub Actions script also appears to automatically close issues after a period of inactivity, which may serve to mask unresolved problems.

The Register has covered some of the issues Claude flagged in its analysis, like the caching issue and claims by AMD's AI director Stella Laurenzo that Claude's responses have been getting worse. Others have yet to be substantiated, such as one claim that "Claude autonomously deleted 35,254 production customer message records and 35,874 billing transactions belonging to a real paying customer (JIXEN)."

The individual or bot account behind this post has made no other posts. The Register has attempted to contact Jixen Enterprises Private Limited, which appears to be a private company registered in India, to check on that claim but we've not heard back. Developers have reported data loss from using Claude Code and other models. But if this occurred, no one has ruled out user error.

In any event, Claude is capable of citing actual GitHub issue posts to justify its "reasoning," so the general trend – of a growing number of reports about quality – is evident.

The model points to issues like "Claude Code's prediction-first behavior is dangerous on capital-at-risk projects" #46212, "Claude Code is unusable for complex engineering tasks with the Feb updates" #42796 (addressed by Claude Code head Boris Cherny), "Artificial degradation, Acquisition Bias, and unacceptable compute throttling for paid users" #46949, and "Opus 4.6: Severe quality degradation on iterative coding tasks" #46099 to justify its conclusion.

Data from Margin Lab, however, suggests that Claude Opus 4.6 has at least maintained its score on the SWE-Bench-Pro test. Assessments conducted since February show some variation but no substantive change.

Anthropic did not immediately respond to a request to comment on Claude quality concerns.®

Apple update turns Czech mate for locked-out iPhone user • The Register

Sun, 12 Apr 2026 09:35:36 +0000

A university student in the US is in data limbo after Apple removed a character from its Czech keyboard, preventing him from entering his iPhone passcode.

Connor Byrne, 21, adopts the uncommon but security-minded approach to iPhone passcodes, using an alphanumeric string instead of the standard four-number passcode.

He updated his iPhone 13 from iOS 18 to iOS 26.4 on April 5, but in doing so lost the ability to enter his passcode. He has been locked out of the device ever since.

This is because iOS 18 was the last operating system version that allowed iPhone users to enter the special character – in this case, the caron/háček (ˇ) – using the old keyboard on the lock screen.

It has left Byrne without access to his device, which, given its age and chipped screen, does not hold much value, unlike the old photos stored on it, which carry sentimental importance.

The student has not backed up the files to iCloud either, so they cannot be retrieved via a separate device. Apple support staff have suggested the only way to regain access to the iPhone 13 is by restoring it, which would erase the files of value.

Byrne was hoping that the next update, 26.4.1, would introduce a fix for this, but its release this week has not helped.

"The phone's very cracked, so, at this point, the photos contained in it are more valuable than the ability to use the phone itself," he told The Register. "They're the main data that I care about and haven't backed up."

"I don't anticipate a bespoke solution being provided, but I'm hopeful that the issue will be resolved in the next iOS update."

When the háček could still be used in the iPhone's passcode, it sat on the bottom row of the keyboard, while just above it was an acute accent mark.

Post-update, when entering the passcode, the keyboard now displays an identical accent mark in the háček's place, a feature Byrne described as "pointless; they're encoded the same."

"I've bought a cheap Android phone to use while I wait for a fix," he added. "I'll give it a month or two and will buy a nicer Android phone if the dust settles without a fix."

Given that iOS 18 was released in 2024, and Apple has not reintroduced the háček since, it seems unlikely Cupertino will make good on the student's hopes, especially considering that he is not the only user to encounter the same issue in recent weeks.

During in-house testing, which involved taking an iPhone 16 from iOS 18.5 to iOS 26.4.1, The Register found that Apple has kept the háček in the Czech keyboard, but removed the ability to use it in a custom alphanumeric passcode. The OS will not allow users to input the háček as a character. The key's animation triggers, as does the keyboard's key-tap sound, but the character is not entered into the string.

If the student were able to get into his iPhone 13, he would find the háček in his keyboard as it used to be before he updated it. It is only the lock-screen keyboard that replaces it with a second acute accent mark.

Alas, Byrne has gone to great lengths to tinker and tease iOS into accepting or finding the háček, or to find tricky ways of bypassing it.

He tried entering the same accent mark that replaced the háček, in the hope that it was simply displaying incorrectly. He also researched downgrading to iOS 26.3.1, with a view to changing the passcode to one that's compatible with the new keyboard, to no avail.

Long-pressing every key to reveal a hidden háček did not work, nor did writing the password on paper (and also with a computer word processor to account for handwriting errors), and using AutoFill to scan it in. In this case, he said that the háček was only read as a quotation mark or degree sign.

Apple Support arranged for Byrne to attend a Genius Bar appointment, where the staffer behind the desk made no progress and even started restoring the phone without seeking the student's consent.

"He provided no recommendations before doing so," he said.

And if you're wondering "why not enable Face ID in the first place? Biometrics are pretty secure." Well, it's not secure enough for this user, and it wouldn't matter either, even if it did meet his standards.

"I don't consider Face ID secure enough because it provides no protection in cases where someone has control of both you and the phone – police or customs, for example."

"It wouldn't have helped anyway, since you have to enter the passcode once after updating to enable Face ID."

For the same reason, plugging in an external keyboard is also a no-go since freshly updated iPhones are placed in what's known as a Before First Unlock state, which prevents wired accessories from working until the passcode is entered.

The Register contacted Apple multiple times to get its side of things, but it did not respond. ®

CPUID hijacked to serve malware as HWMonitor downloads • The Register

Sat, 11 Apr 2026 21:08:27 +0000

Visitors to the CPUID website were briefly exposed to malware this week after attackers hijacked part of its backend, turning trusted download links into a delivery mechanism for something far less welcome.

The issue hit tools like HWMonitor and CPU-Z, with users on Reddit and elsewhere starting to notice something wasn't right when installers tripped antivirus alerts or showed up under odd names. One example that did the rounds had the HWMonitor 1.63 update pointing to a file called "HWiNFO_Monitor_Setup.exe," which is not what anyone went there to download, and a pretty clear sign that something upstream had been tampered with.

CPUID has since confirmed the breach, pinning it on a compromised backend component rather than tampering with its software builds.

"Investigations are still ongoing, but it appears that a secondary feature (basically a side API) was compromised for approximately six hours between April 9 and April 10, causing the main website to randomly display malicious links (our signed original files were not compromised)," one of the site's owners said in a post on X. "The breach was found and has since been fixed."

The files themselves appear to have been left alone and remain properly signed, so it doesn't seem like anyone got into the build process. Instead, the problem sat in front of that, in how downloads were being served. For anyone who hit the site during that stretch, though, that distinction offers little comfort. If the link you clicked had been swapped out, you were pulling whatever it pointed to, whether you realized it or not.

Analysis shared by vx-underground says the malicious installer appears to have targeted 64-bit HWMonitor users and included a fake CRYPTBASE.dll designed to blend in with legitimate Windows components. That DLL then reached out to a command-and-control server to pull down additional payloads.

From there, things escalate. Analysis suggests the malware tries to stay off disk as much as possible, leaning on PowerShell and running largely in memory. It also pulls down additional code and compiles a .NET payload on the victim machine before injecting it into other processes. There are also signs it's going after browser data. In testing, it was seen interacting with Google Chrome's IElevation COM interface, which can be used to access and decrypt stored credentials.

The same analysis suggests links to infrastructure used in earlier campaigns, including one targeting FileZilla users, hinting that this wasn't a one-off experiment but part of a broader playbook.

CPUID says the issue is now fixed, but there's still no detail on how that API was accessed or how many people actually pulled the bad downloads. Even so, it's another reminder that attackers don't need to touch the code itself to cause harm. ®

Apple opts everyone into having their Photos analyzed by AI • The Register

Sat, 11 Apr 2026 01:56:33 +0000

Apple last year deployed a mechanism for identifying landmarks and places of interest in images stored in the Photos application on its customers iOS and macOS devices and enabled it by default, seemingly without explicit consent.

Apple customers have only just begun to notice.

The feature, known as Enhanced Visual Search, was called out last week by software developer Jeff Johnson, who expressed concern in two write-ups about Apple's failure to explain the technology, which is believed to have arrived with iOS 18.1 and macOS 15.1 on October 28, 2024.

In a policy document dated November 18, 2024 (not indexed by the Internet Archive's Wayback Machine until December 28, 2024, the date of Johnson's initial article), Apple describes the feature thus:

Enhanced Visual Search in Photos allows you to search for photos using landmarks or points of interest. Your device privately matches places in your photos to a global index Apple maintains on our servers. We apply homomorphic encryption and differential privacy, and use an OHTTP relay that hides [your] IP address. This prevents Apple from learning about the information in your photos. You can turn off Enhanced Visual Search at any time on your iOS or iPadOS device by going to Settings > Apps > Photos. On Mac, open Photos and go to Settings > General.

Apple did explain the technology in a technical paper published on October 24, 2024, around the time that Enhanced Visual Search is believed to have debuted. A local machine-learning model analyzes photos to look for a "region of interest" that may depict a landmark. If the AI model finds a likely match, it calculates a vector embedding – an array of numbers – representing that portion of the image.

The device then uses homomorphic encryption to scramble the embedding in such a way that it can be run through carefully designed algorithms that produce an equally encrypted output. The goal here being that the encrypted data can be sent to a remote system to analyze without whoever is operating that system from knowing the contents of that data; they just have the ability to perform computations on it, the result of which remain encrypted. The input and output are end-to-end encrypted, and not decrypted during the mathematical operations, or so it's claimed.

The dimension and precision of the embedding is adjusted to reduce the high computational demands for this homomorphic encryption (presumably at the cost of labeling accuracy) "to meet the latency and cost requirements of large-scale production services." That is to say Apple wants to minimize its cloud compute cost and mobile device resource usage for this free feature.

With some server optimization metadata and the help of Apple's private nearest neighbor search (PNNS), the relevant Apple server shard receives a homomorphically-encrypted embedding from the device, and performs the aforementioned encrypted computations on that data to find a landmark match from a database and return the result to the client device without providing identifying information to Apple nor its OHTTP partner Cloudflare.

Thus, Apple unilaterally began running people's Photos through a locally running machine-learning algorithm that analyzes image details (on a purely visual basis, without using location data) and creates a value associated with what could be a landmark in each picture. That value is then used on a remote server to check an index of such values stored on Apple servers in order to label within each snap the landmarks and places found in Apple's database.

Put more simply: You take a photo; your Mac or iThing locally outlines what it thinks is a landmark or place of interest in the snap; it homomorphically encrypts a representation of that portion of the image in a way that can be analyzed without being decrypted; it sends the encrypted data to a remote server to do that analysis, so that the landmark can be identified from a big database of places; and it receives the suggested location again in encrypted form that it alone can decipher.

If it all works as claimed, and there are no side-channels or other leaks, Apple can't see what's in your photos, neither the image data nor the looked-up label.

Apple claims that its use of this homomorphic encryption plus what's called differential privacy – a way to protect the privacy of people whose data appears in a data set – precludes potential privacy problems.

"Apple is being thoughtful about doing this in a (theoretically) privacy-preserving way, but I don’t think the company is living up to its ideals here," observed software developer Michael Tsai in an analysis shared Wednesday. "Not only is it not opt-in, but you can’t effectively opt out if it starts uploading metadata about your photos before you even use the search feature. It does this even if you’ve already opted out of uploading your photos to iCloud."

Tsai argues Apple's approach is even less private than its abandoned CSAM scanning plan "because it applies to non-iCloud photos and uploads information about all photos, not just ones with suspicious neural hashes."

Nonetheless, Tsai acknowledges Apple's claim that data processed in this way is encrypted and disassociated with the user's account and IP address.

While there's no evidence at this point that contradicts Apple's privacy assertions, the community concern has more to do with the way in which Apple deployed this technology.

"It’s very frustrating when you learn about a service two days before New Years and you find that it’s already been enabled on your phone," said Matthew Green, associate professor of computer science at the Johns Hopkins Information Security Institute in the US.

Apple gives fanbois The Sweetest Thing: A delete button for that U2 album

FLASHBACK

The Register asked Apple to comment, and as usual we've received no reply. We note that lack of communication is the essence of the community discontent.

"My objection to Apple's Enhanced Visual Search is not the technical details specifically, which are difficult for most users to evaluate, but rather the fact that Apple has taken the choice out of my hands and enabled the online service by default," said Johnson in his second post.

He told The Register that it's unclear whether the data/metadata from your Photos library is uploaded before you even have a chance to disable the opt-out setting.

"I don't think anybody knows, and Apple hasn't said," Johnson observed. ®

Smart TVs and voice assistants are the next gatekeepers • The Register

Fri, 10 Apr 2026 05:14:40 +0000

Europe's broadcasters say smart TVs and voice assistants are fast becoming the next Big Tech gatekeepers, with little sign of Brussels stepping in.

The warning comes in an open letter addressed to European Commission executive vice-president Teresa Ribera, signed by industry groups including the Association of Commercial Television and Video on Demand Services in Europe (ACT) and the European Broadcasting Union (EBU).

The letter urges the Commission to bring connected TV operating systems and virtual assistants within the scope of the Digital Markets Act (DMA), arguing that both now sit squarely between audiences and the content they're trying to watch or hear, with growing influence over how that content is surfaced.

The concern isn't the screens themselves, but the software layer deciding what gets shown, whether that's a recommendation row on a TV homepage or the answer served up when a user asks a voice assistant for something to watch. That layer, broadcasters argue, now controls search, recommendations, and app visibility in much the same way app stores and search engines do on phones and PCs – only without the same regulatory scrutiny.

The DMA is supposed to rein in "gatekeepers" with rules against self-preferencing and unfair access, but so far, no connected TV platforms or virtual assistants have been put in that bucket, a gap the letter says is only getting wider.

"With the future viability of many European TV broadcasters at stake, and with millions of EU businesses and consumers relying on CTVs to promote and access an expanding range of content via TV applications, it is crucial that the Commission designate major TV operating systems as gatekeepers and ensure adequate oversight to guarantee fairness and contestability," the letter states.

"While CTVs can offer significant opportunities for European businesses to develop and compete – not only in audiovisual content, but also in gaming, health and other applications – these opportunities risk being undermined by entrenched gatekeeping practices."

The fear is that if a platform controls both how content is delivered and how it's found, it doesn't take much imagination to see how it might nudge things its own way, whether that's pushing its own services, striking cozy deals, or quietly steering recommendations out of public view.

For broadcasters, particularly public service outfits already under pressure, there's the risk of being quietly edged out of view on the very devices audiences now use to access TV and radio.

Virtual assistants complicate things further. Unlike a single operating system, they operate across TVs, smartphones, cars, and smart speakers, acting as a universal interface for content discovery. That reach, the groups argue, effectively turns them into gatekeepers in all but name, even if they don't yet meet the DMA's formal thresholds.

Brussels is essentially being told to act early for once, either by designating these platforms under the DMA or by at least opening the hood before user habits set and market power quietly locks in. ®

Godot maintainers struggle with 'demoralizing' AI slop PRs • The Register

Thu, 09 Apr 2026 21:35:04 +0000

Rémi Verschelde, a maintainer of the open source Godot game engine, is the latest to complain about the impact of "AI slop PRs [pull requests]", which he says "are becoming increasingly draining and demoralizing for Godot maintainers."

His post was prompted by a comment from Adriaan de Jongh, game designer and director of small gaming company Hidden Folks, who said that LLM-generated PRs for Godot are a "massive time waster for reviewers ... changes often make no sense, descriptions are extremely verbose, users don't understand their own changes ... it's a total shitshow."

A comment noted that the Blender 3D design project is facing the same issue and has recently proposed an AI contributions policy, following others including the Linux Foundation, Fedora, Firefox, Ghostty, Servo and LLVM.

Verschelde appealed for "more funding so we can pay more maintainers to deal with the slop," and also spoke of the conflict between being welcoming to new contributors to let "any engine user have the possibility to make an impact" while also dealing with the onslaught of useless PRs.

"I don't know how long we can keep it up," he said.

GitHub itself is to blame, according to some comments, since the company is a big AI advocate. "This platform incentivizes this kind of behavior," said one; and another that it "is just exhausting to watch all this play out and GitHub promoting this, not fighting it."

Linux distro Gentoo is in the process of migrating from GitHub to Codeberg thanks to "continuous efforts to force Copilot usage for our repositories."

One project, the self-hosting toolkit Coolify, has created an Anti Slop GitHub Action, which its developer claims "could have closed 98 percent of slop PRs." The developer is not opposed to AI itself, and stated that "AI is one of the best things to ever be released and when used with experience and properly according to project guidelines it will pass all checks."

GitHub director of open source programs Ashley Wolf acknowledged the problem of "what happens when low-quality contributions arrive at scale" last week, though choosing her words carefully so as not to blame AI itself. According to Wolf, "maintainers have always dealt with noisy inbound." Nevertheless, GitHub is introducing features to make AI slop easier to deal with, including PR deletion from the GitHub UI (user interface) which she said is coming soon.

Wolf also mentioned relevant features that have already shipped, including the ability to limit PRs to collaborators or disable them entirely. And maintainers can enforce temporary interaction limits for specific users.

Further refinements are under consideration. Wolf mentioned criteria-based gating, such as requiring that a PR be linked to an existing issue, or defining other rules that contributions must meet. There is also the inevitable suggestion that AI can be used to fix the problem it created, via automated triage.

Wolf's post follows the creation of an official GitHub discussion on the subject earlier this month, as we reported. A GitHub product manager contacted us to state that "we don't think counting AI-generated PRs is the right metric," showing again the tension between the company's strong promotion of AI and the evidence of the damage it is doing to open source. ®

Copilot swallows your browser. You're welcome • The Register

Thu, 09 Apr 2026 05:13:31 +0000

Microsoft is rolling out a Copilot update to Windows Insiders that embeds web browsing directly into the assistant, opening links in a side panel rather than launching your default browser.

The plan is that users of the Copilot app in Windows will show content in the assistant's window "so you don't lose context."

Microsoft to auto-launch Copilot in Edge whenever you click a link from Outlook

Copilot will also (with permission) have access to the context of tabs opened in that conversation, so the assistant can look across them when responding to user prompts. Opened tabs will be saved with the conversation so that they can be returned to, and, if a user chooses to enable it, passwords and form data can be synchronized.

Enabling password and form data synchronization might give some users pause for thought, particularly after the Windows Recall fiasco, but users worried about Redmond slurping data should probably consider an alternative to Windows anyway.

At first glance, it looks like embedding Edge into Copilot via the WebView2 control is an attempt to steer the user away from their default browser. Convenient, yes. Good for competition, possibly not. We asked Microsoft whether this would be an opt-in experience and which browser was being used, but, other than acknowledging receipt of our questions, the company did not respond.

The update has raised a few eyebrows among browser vendors. Bruce Lawson, Vivaldi's Technical Communications Officer, told us: "If it's not opt-in, then it's bad behavior. Over the last 25 years, people have become accustomed to clicking links, and that opens their default browser with their preferred settings, stored passwords, preferred font size, and preferred security settings.

"Pulling that rug from under users' feet is impertinent and discourteous. Whether it circumvents DMA or other competition regulations is for lawyers and regulators to decide, but the eternal arrogance of gatekeepers is self-evident."

The update is currently a preview and therefore subject to change. The rollout to all Insider Channels will be gradual (Vivaldi told us it had yet to see the build).

The Copilot app is also being tweaked elsewhere. Microsoft stated: "As part of this update, some features like Podcasts and Study and Learn mode from Copilot.com are getting added, while others may be pulled back while we iterate on the experience; we will add priority features back in before the updated app is generally available."

For Copilot app users, opening web links alongside conversations is perhaps a useful feature. However, for browser vendors already dealing with Microsoft's preferred way of doing things, the update could be seen as another attempt to keep a user safely within Redmond's purview.

The Reg doubts some of our readers will approve either. ®

Users fume at Outlook.com email 'carnage' • The Register

Thu, 09 Apr 2026 05:13:31 +0000

Updated Microsoft spent last week rejecting emails to Outlook recipients after what appears to be either a fault or overzealous blocking rules.

The problem affects certain IP addresses, whose emails are rejected due to falling foul of reputation rules or appearing on a block list.

A Register reader told us, "At the back end of January we noticed a sudden spike in customers static IP's being rejected by only Microsoft Outlook free / personal accounts."

The message returned was a 550, telling customers to contact their Internet Service Provider (ISP) "since part of their network is on our block list."

A block list is a good thing. It helps stem the flow of spam from networks or addresses associated with junk email. However, the confusing thing for our reader is that his company was not on Microsoft's naughty step for email. A glance at Microsoft's Smart Network Data Service (SNDS) showed no issues with the IP.

"We're also a member of their JMRP (Junk Mail Reporting Program)," our reader went on, "which is intended to inform us when people are reporting spam sent from our IP's - except, we never get any reports."

The problem worsened in February. On Microsoft's support forums, users began to complain about similar issues as the IP net presumably widened. One wrote "We are currently experiencing a critical and recurring email delivery issue affecting recipients at outlook.com, live.com, hotmail.com, and msn.com," and provided a copy of an error that suggested that the mail server has been "temporarily rate limited due to IP reputation."

The user drily noted, "Although the error indicates rate limiting, in practice no emails are being delivered."

A large number of users, ranging from the administrator of a server sending automated notifications on behalf of Estonian Public Libraries to an email provider for healthcare professionals, chimed in to confirm that they, too, were having delivery problems and that Microsoft support was not helpful.

Our reader told us, "We've seen customers struggling to send invoices, order delivery notifications, authentication codes - all sorts, which have been perfectly acceptable to Microsoft / Outlook for many years - now rejected, or blocked.

"Customers rarely read, or understand DSN's - they jump to blaming the ISP or sender, and then head off to find someone else."

Unsurprisingly, our reader spoke on condition of anonymity. After all, nobody wants to be the ISP that has to say, "Yeah, we can deliver your email anywhere but Outlook.com" to customers.

We asked Microsoft if it had any comment to make, but other than acknowledging our questions, the company did not respond.

Blocking email from spammers is a good thing, and anything that reduces the amount of junk that clutters up inboxes is to be applauded. However, when there is an error, customers need a rapid and transparent process for resolution. Every failed delivery of an invoice or receipt due to overzealous or misapplied rules can chip away at a business's reputation, through no fault of the owner. ®

Updated at 13.33 UTC on March 6, 2025, to add:

Microsoft has finally responded, days after this article was published. A spokesperson told The Register:

"We are working to address a temporary rate‑limit issue that may be causing some messages to be incorrectly throttled when sent from a specific IP address. Customers who continue to experience issues sending emails should contact our Support team or raise a ticket in their Admin portal to apply the appropriate mitigation."

HR may have to cajolle employees to use AI: Gartner • The Register

Thu, 09 Apr 2026 05:13:31 +0000

If you buy AI, employees will come and take a look, but they won't necessarily change the way they work. For that, you may have to get human resources involved.

IT consultancy Gartner says as much in its recent report "Guide Managers to Effectively Integrate AI Into Employees' Work."

The enterprise whisperer says that its July 2025 survey of nearly 3,000 employees showed that 46 percent of managers are experimenting with AI to improve their work, compared to just 26 percent of employees.

A separate survey conducted at the same time found that just 14 percent of managers said that they didn't face any challenges encouraging their teams to use AI. AI tools, in other words, don't sell themselves (except perhaps in software development).

From this, Carmen von Rohr, senior principal in Gartner's HR practice, concludes that chief human resource officers have relied too much on employees to integrate AI tools into their jobs. To improve AI adoption, CHROs are advised to focus on supporting managers to undertake the organizational change necessary to meet the expectations of senior leadership.

More than any prior technology, Gartner argues, AI implementation requires change management.

In other words, HR leaders need to focus on communication and sensitivity to employee needs. If managers rush to implement business transformation plans, they risk creating "operational and emotional resistance" among employees. Just as asking IT professionals to train their overseas replacements risks rebellion, urging employees to embrace AI coworking can create pushback, especially if accompanied by layoffs.

Given that 46 percent of US voters believe AI will hurt the economy, according to a recent Data for Progress poll, some forethought seems advisable.

Gartner would have CHROs help managers with their AI integration efforts by looking at the needs and expectations of different teams in terms of AI training and support. HR leaders should also prepare managers for potential emotional resistance from employees and for communicating effectively with senior leaders who may not have realistic expectations.

In addition, the consultancy sees a role for HR leaders in clarifying how potential AI-related productivity gains should be allocated – a return on investment that the majority of CEOs still haven't seen.

That recommendation follows from a July 2025 Gartner survey of 114 HR leaders that found a mere 7 percent of organizations offer guidance about how one should use time savings derived from AI tools.

And before that question can even be answered, companies need to settle internal disagreements about how projected time saved should be allocated. Based on the survey, 55 percent of HR leaders preferred to see saved time applied to projects outside of core job roles, compared to just 28 percent of managers.

Debating how AI's supposed productivity bounty will be spent seems premature, however, when organizations are still struggling to sell their workers on AI. ®