Agregátor RSS

Software security testing outfit Checkmarx has become the latest organization caught up in an ongoing attack on security-tool providers. The biz said data posted online appears to have come from one of its GitHub repositories after the Lapsus$ extortion crew claimed to have dumped the company’s source code, secrets, and other sensitive data. In a Sunday update, Checkmarx said the investigation remains ongoing, and it's working to "verify the nature and scope" of the data. Current evidence, however, suggests that "this data originated from Checkmarx's GitHub repository, and that access to that repository was facilitated through the initial supply chain attack of March 23, 2026." The security shop has since locked down access to the affected repo, and said if the investigation determines any customer information was posted online, it will notify "all relevant parties immediately." A day earlier, Lapsus$ data thieves added Checkmarx to the list of victims on its leak site. In a post shared on X by Dark Web Informer, the extortionists claimed to have dumped a raft of sensitive information including source code, API keys, MongoDB and MySQL login credentials, and employee details. Checkmarx did not respond to The Register's inquiries about the stolen data and Lapsus$ claims. The vendor, on Sunday, promised a "more detailed update within 24 hours," as this supply chain SNAFU ripples across the security and developer tools landscapes. From Trivy to Checkmarx The initial attack, which Checkmarx referenced in its advisory, occurred on March 23, when a new-ish cybercrime crew called TeamPCP used CI/CD secrets stolen from Trivy, which they initially compromised in late February. Trivy is an open source vulnerability scanner maintained by Aqua Security. On March 16, TeamPCP injected credential-stealing malware into the scanner, hoovered up a ton of developers' secrets, cloud credentials, SSH keys, and Kubernetes configuration files, then planted persistent backdoors on developers' machines. This intrusion also gave the attackers an initial access vector into several other open source tools including LiteLLM, Telnyx and KICS, an open source static analysis tool maintained by Checkmarx. On March 23, TeamPCP injected the same credential-stealing malware into KICS, and pushed poisoned images to the official checkmarx/kics Docker Hub repository maintained by Checkmarx. "Analysis of the poisoned image indicates that the bundled KICS binary was modified to include data collection and exfiltration capabilities not present in the legitimate version," Socket's research team wrote in its earlier analysis of the Checkmarx supply chain attack. "Our investigation found evidence that the malware could generate an uncensored scan report, encrypt it, and send it to an external endpoint, creating a serious risk for teams using KICS to scan infrastructure-as-code files that may contain credentials or other sensitive configuration data," the supply chain security researchers wrote. Then it got even worse. The ripple effect In addition to the trojanized KICS image, the miscreants compromised additional Checkmarx developer tooling including Checkmarx GitHub Actions and two Open VSX plugins. "On March 23, 2026, Checkmarx was the target of a cybersecurity supply chain incident which affected two specific plugins distributed via the Open VSX marketplace and two of our GitHub Actions workflows," Checkmarx said in its initial security advisory. Late last week, Socket researchers revealed that open source password manager Bitwarden's CLI was also compromised as part of the Checkmarx intrusion. This vastly expands the potential blast radius of the attack because more than 10 million users and over 50,000 businesses use Bitwarden, which claims to be the No. 2 enterprise password manager. "Attackers are deliberately targeting the tools developers are told to trust most: security scanners, password managers, and other high-privilege software wired directly into developer environments. This is why the fallout can get big very quickly," Socket CEO Feross Aboukhadijeh told The Register on Monday. "When you compromise a tool like this, you are not just compromising one vendor," he said. "You are potentially gaining access to GitHub tokens, cloud credentials, CI secrets, npm publish access, and the downstream environments those tools touch." Plus, he told us, the attackers are specifically targeting security tools and vendors in this ongoing campaign. "The threat actors behind these attacks hold a deeply hostile view of the current state of security tooling and vendors," Aboukhadijeh said. "They are explicitly targeting the open source security ecosystem and developer infrastructure." After initially compromising Trivy, LiteLLM, KICS, and other open source security tools, TeamPCP partnered with ransomware and extortion groups including Vect and Lapsus$, bragging on BreachForums that "we will pull off even bigger supply chain operations. We will chain these compromises into devastating follow-on ransomware campaigns." In early April, AI training startup Mercor confirmed it was "one of thousands of companies" affected by the LiteLLM supply-chain attack after Lapsus$ offered 4 TB, including 939 GB of Mercor source code, for sale to the highest bidder. "Instead of just bypassing security tools, they are going after them directly," Aboukhadijeh told us. "They know these products are deeply embedded, highly trusted, and often massively overprivileged. That makes them incredibly effective choke points for both data theft and downstream propagation." ®

Vendor confirms repo data exposure after Lapsus$ claims source code, secrets dump

Software security testing outfit Checkmarx has become the latest organization caught up in an ongoing attack on security-tool providers. The biz said data posted online appears to have come from one of its GitHub repositories after the Lapsus$ extortion crew claimed to have dumped the company’s source code, secrets, and other sensitive data.…

Online trading platform Robinhood's account creation process was exploited by threat actors to inject phishing messages into legitimate emails, tricking users into believing their accounts had suspicious activity. [...]

Transakcí jako je prodej kryptoměn, jejich směna nebo využití pro platbu za zboží a služby se může týkat zdanění. Poradíme, co podléhá dani a kdy nic dělat nemusíte.

Pokud okolnosti případu naznačují nízkou společenskou škodlivost pachatelova činu, je povinností soudu to zohlednit, nařídil Ústavní soud. I podmíněný trest pak může být přehnaný.

V sobotu 25. dubna proběhl v Bratislavě čtvrtý ročník konference OpenCamp, na které se mluvilo o otevřené náhradě za špatně fungující slinivku, základech optických sítí, komunikační síti Matrix a dalších tématech.

Na článek s popisem textových režimů čipu ANTIC v počítačích Atari dnes navážeme. Popíšeme si totiž grafické (rastrové) režimy a taktéž si ukážeme, jakým způsobem se řeší jedno z omezení ANTICu: možnost adresovat pouze 4kB video RAM.

Od té doby, co jsme se na otázky z kosmologie dívali naposledy, už je zase nějaký ten týden, proto je na čase se dnes podívat na dalších několik otázek, které mi přišly a pokusit se na ně co nejlépe zodpovědět. Nezdržujme se tedy, a pojďme rovnou na to.

Robert Hallock, který funguje u Intelu jako vice-prezident pro marketing se zaměřením na osobní počítače, vyjádřil rozhořčení ze stavu softwarových optimalizací her pro procesory Intelu…

A new wave of the Glassworm campaign is targeting the OpenVSX ecosystem with 73 "sleeper" extensions that turn malicious after an update. [...]

Jer (Jeremy) Crane, the founder of automotive SaaS platform PocketOS, spent the weekend recovering from a data extinction event caused by the company's AI coding agent in less than 10 seconds.  Not one to let a crisis go to waste, Crane wrote up a post-mortem of the deletion incident in a social media post that tests the saying, "there's no such thing as bad publicity." "[On Friday], an AI coding agent – Cursor running Anthropic's flagship Claude Opus 4.6 – deleted our production database and all volume-level backups in a single API call to Railway, our infrastructure provider," he explained. "It took 9 seconds." According to Crane, the Cursor agent encountered a credential mismatch in the PocketOS staging environment and decided to fix the problem by deleting a Railway volume – the storage space where the application data resided. To do so, it went looking for an API token and found one in an unrelated file.  The token had been created for adding and removing custom domains through the Railway CLI but was scoped for any operation, including destructive ones. This is evidently a feature when it should be a bug. According to Crane, that token would not have been stored if the breadth of its permissions was known. The AI agent used this token to authorize a curl command to delete PocketOS's production volume, without any confirmation check, while also erasing the backup because, as Crane noted, "Railway stores volume-level backups in the same volume." We pause here to allow you to shake your head in disbelief, roll your eyes, or engage in whatever I-told-you-so ritual you prefer. The lessons exemplified by AWS's Kiro snafu and by developers using Google Antigravity and Replit will be repeated until they've sunk in. Railway CEO Jake Cooper responded to Crane's post by saying that the deletion should not have happened and then by saying that's expected behavior. "[W]hile Railway has always built 'undo' into the platform (CLI, Dashboard, etc) as a core primitive, we've kept the API semantics inline with 'classical engineering' developer standards," he wrote. "... As such, today, if you (or your agent) authenticate, and call delete, we will honor that request. That's what the agent did ... just called delete on their production database." Crane told The Register in an email that he was extremely grateful Cooper stepped in on Sunday evening, helped restore his company's data within an hour, and placed further safeguards on the API.  In an email to The Register, Cooper from Railway said, "We maintain both user backups as well as disaster backups. We take data very, VERY seriously. This particular situation was a 'rogue customer AI' granted a fully permissioned API token that decided to call a legacy endpoint which didn't have our 'Delayed delete' logic (which exists in the Dashboard, CLI, etc). We've since patched that endpoint to perform delayed deletes, restored the users data, and are working with Jer directly on potential improvements to the platform itself (all of which so far were currently in active development prior to the events)." That just leaves the blame. "No blaming 'AI' or putting incumbents or gov't creeps in charge of it – this shows multiple human errors, which make a cautionary tale against blind 'agentic' hype," observed Brave Software CEO Brendan Eich. Nonetheless, Crane calls out "Cursor's failure" – marketing safety despite evidence to the contrary – and "Railway's failures (plural)" – an API that deletes without confirmation, storing backups on the production volume, and root-scoped tokens, among other things – without much self-flagellation. Called out about this, Crane insisted there's mea culpa in the mix, but added he also wants accountability from infrastructure providers. "Our core thesis stands," Crane said in his email. "Yes our responsibility was the unknown exposure to a production API key (Railway doesn't currently allow restrictions on keys). "But, still a cautionary tale and discovery of tooling and infrastructure providers. The appearance of safety (through marketing hyperbole) is not safety. And when we pay for those services and they are not really there, it is worth an oped. We are building so fast these things are going to keep happening." Nonetheless, Crane said, he's still extremely bullish on AI and AI coding agents, a stance that's difficult to reconcile with his interrogation of Opus, wherein the model describes how it ignored Cursor's system-prompt language and PocketOS's project rules: Opus in its Cursor harness flatly admits its errors – not that it means anything given the model's inability to learn from its mistakes and to feel remorse that might constrain future destructive action. Crane said he believes companies involved in AI understand these risks and are actively working to prevent them. "Even when they put in safeguards, it can still happen," he said. "Cursor had a similar issue about nine months ago, and there was a lot of publicity. They built a lot of tooling to force agents to run certain commands through humans, but they did not apply it here, and it still went off the rails, which happens from time to time with these AIs." Crane said he believes the benefits outweigh the risks. "As a software developer, I've been doing this for 15 years, so I'm not some vibe coder who picked it up in the last few months," he said. "The velocity at which you can create good code with the right instructions and tooling is unparalleled. If you understand systems, the ability to work with codebases you don't personally know but can still understand has also been unparalleled." This introduces novel risks, he said. "Railway's defense has always been that an API key should only be accessed by a human, which is true and has always been the case," he explained. "Now, when a computer is in control and you do not know what it is doing, what happens?" Crane emphasized how helpful Railway's CEO has been through this process and said he has about 50 services running there. "These are the challenges we face as we move faster and faster in software development, with AI, and the tooling is trying to keep up as fast as it can," he said. "I like using the word 'tooling' because, in my view, it reflects the challenges we face today, much like the early days of the dot-com era. Back then, websites would crash, database data would be lost, and there were hardware and networking issues. Those were the technical hurdles of that time. These are the challenges of our era." What to take from this data deletion and resurrection? According to Cooper, it's a market opportunity. "There's a massive, massive opportunity for 'vibecode safely in prod at scale' 1B+ developers who look like [Jer Crane], don't read 100 percent of their prompts, and want to build are coming online. For us toolmakers, the burden of making bulletproof tooling goes up. We live in exciting times." ®

Nový ovladač Steam Controller jde do prodeje 4. května. Cena je 99 eur.

Open source software with more than 1 million monthly downloads was compromised after a threat actor exploited a vulnerability in the developers’ account workflow that gave access to its signing keys and other sensitive information.

On Friday, unknown attackers exploited the vulnerability to push a new version of element-data, a command-line interface that helps users monitor performance and anomalies in machine-learning systems. When run, the malicious package scoured systems for sensitive data, including user profiles, warehouse credentials, cloud provider keys, API tokens, and SSH keys, developers said. The malicious version was tagged as 0.23.3 and was published to the developers’ Python Package Index and Docker image accounts. It was removed about 12 hours later, on Saturday. Elementary Cloud, the Elementary dbt package, and all other CLI versions weren't affected.

Assume compromise

“Users who installed 0.23.3, or who pulled and ran the affected Docker image, should assume that any credentials accessible to the environment where it ran may have been exposed,” the developers wrote.

Read full article

Comments

Canadian authorities have arrested three men for operating an "SMS blaster" device that pretends to be a cellular tower to send phishing texts to nearby phones. [...]

A Chinese national accused of carrying out cyberespionage operations for China's intelligence services has been extradited from Italy to the United States to face criminal charges. [...]

Sociální sítě i další služby a platformy na internetu už nejsou, co bývaly. Uživatel už často není na prvním místě, důležitější začíná být na něm zbohatnout.

Digital intruders recently broke into two major tech suppliers - utility-technology firm Itron and medical-device maker Medtronic - according to filings with federal regulators. Itron, in a late Friday US Securities and Exchange Commission (SEC) filing, said it was notified about the unauthorized third-party break-in on April 13.  The $4 billion company that provides smart meters, sensors, and software for energy, water, and city management said it alerted law enforcement and worked with external cybersecurity advisors to investigate the intrusion. "The Company took action to remediate and remove the unauthorized activity and has not observed any subsequent unauthorized activity within its corporate systems," according to Itron's 8-K report. "Further, no unauthorized activity was observed in the customer hosted portion of its systems." The breach didn't affect Itron's operations, the disclosure said, adding that "Itron currently expects that a significant portion of its direct costs incurred relating to the incident will be reimbursed by its insurers." Itron declined to answer our questions about the breach, including how criminals gained initial access to its systems and whether they deployed ransomware or made an extortion demand. Meanwhile, in a Friday disclosure and SEC filing, med-tech firm Medtronic said an "unauthorized party accessed data in certain Medtronic corporate IT systems." Medtronic's breach disclosure follows ShinyHunters' claims that the data-theft-and-extortion crew broke into the medical device business and compromised "over 9M records containing PII and other terabytes of internal corporate data." ShinyHunters set an April 21 deadline for the company to pay an undisclosed extortion demand, or see its stolen data leaked. Medtronic did not immediately respond to The Register's inquiries about the breach. The $107 billion company didn't say when the breach occurred, but noted the intrusion did not impact its "products, patient safety, connections to our customers, our manufacturing and distribution operations, our financial reporting systems or our ability to meet patient needs." Medtronic says its corporate IT network remains separate from the product, manufacturing, distribution, and hospital-customer networks. "We are working to identify any personal information that may have been accessed and will provide notifications and support services as needed," the company posted on its website. In March, another med-tech company Stryker said a cyberattack - linked by researchers to an Iran-aligned crew with ties to the country's intelligence agency - disrupted its global network, snarling ordering and shipping systems for nearly three weeks. On April 1, the company said it is "fully operational across our global manufacturing network." ®

Itron, Medtronic disclose breaches in Friday filings

Digital intruders recently broke into two major tech suppliers - utility-technology firm Itron and medical-device maker Medtronic - according to filings with federal regulators.…

Vysloužilý smartphone může fungovat jako domácí server bez dodatečných nákladů • Velkou výhodou je integrovaná baterie sloužící jako záložní zdroj • Pro bezpečný trvalý provoz je vhodné omezit nabíjení baterie chytrou zásuvkou

Algorithmic advances are steadily lowering the bar for quantum attacks—even before large-scale hardware exists.

Online data is generally pretty secure. Assuming everyone is careful with passwords and other protections, you can think of it as being locked in a vault so strong that even all the world’s supercomputers, working together for 10,000 years, could not crack it.

But last month, Google and others released results suggesting a new kind of computer—a quantum computer—might be able to open the vault with significantly fewer resources than previously thought.

The changes are coming on two fronts. On one, tech giants such as IBM and Google are racing to build ever-larger quantum computers: IBM hopes to achieve a genuine advantage over classical computers in some special cases this year, and an even more powerful “fault-tolerant” system by 2029.

On the other front, theorists are refining quantum algorithms: Recent work shows the resources needed to break today’s cryptography may be far fewer than earlier estimates.

The net result? The day quantum computers can break widely used cryptography—portentously dubbed “Q-Day”—may be approaching faster than expected.

The Quantum Hardware Race

Quantum computers are built from quantum bits, or qubits, which use the counterintuitive properties of very tiny objects to carry out computations in a different and sometimes far more efficient way from traditional computers.

So far the technology is in its infancy, with the major goal to increase the number of qubits that can be connected to work as a single computer. Bigger quantum computers should be much better at some things than their traditional counterparts—they will have a “quantum advantage.”

Late last year, IBM unveiled a 120-qubit chip which it hopes will demonstrate a quantum advantage for some tasks.

Google also recently announced it planned to speed up its move to adopt encryption techniques that should be safe against quantum computers, known as post-quantum cryptography.

Alongside these tech giants, newer approaches are also flourishing. PsiQuantum is using light-based qubits and traditional chip-manufacturing technology. Experimental platforms such as neutral-atom systems have demonstrated control over thousands of qubits in laboratory settings.

In response, standards bodies and national agencies are setting increasingly concrete timelines for moving away from common encryption systems that are vulnerable to quantum attack.

In the United States, the National Institute of Standards and Technology (NIST) has proposed a transition away from quantum-vulnerable cryptography, with migration largely completed by 2035. In Australia, the Australian Signals Directorate has issued similar guidance, urging organizations to begin planning immediately and transition to post-quantum cryptography by 2030.

Algorithms Make the Lock-Picking Faster

Hardware is only half the story. Equally important are advances in quantum algorithms—ways to use quantum computers to attack encryption.

Much interest in quantum computer development was spurred by Peter Shor’s 1994 discovery of an algorithm that showed how quantum computers could efficiently find the prime factors of very large numbers. This mathematical trick is precisely what you need to break the common RSA encryption method.

For decades, it was believed a quantum computer would need millions of physical qubits to pose a threat to real-world encryption. This is far bigger than current systems, so the threat felt comfortably distant.

That picture is now changing.

In March 2026, Google’s Quantum AI team released a detailed study showing that far fewer resources may be needed to attack a different kind of encryption which uses mathematical objects called elliptic curves. This is what systems including Bitcoin and Ethereum use—and the study shows how a quantum computer with fewer than half a million physical qubits may be able to crack it in minutes.

That’s still a long way beyond current quantum computers, but around ten times less than earlier estimates.

At the same time, a March 2026 preprint from a Caltech—Berkeley—Oratomic collaboration explores what might be possible using neutral-atom quantum computers. The researchers estimate that Shor’s algorithm could be implemented with as few as 10,000–20,000 atomic qubits. In one design they propose, a system with around 26,000 qubits could crack Bitcoin’s encryption in a few days, while tougher problems like the RSA method with a 2048-bit key would need more time and resources.

In plain terms: The codebreakers are becoming more efficient. Advances in algorithms and design are steadily lowering the bar for quantum attacks, even before large-scale hardware exists.

What Now?

So what does this mean in practice?

First, there is no immediate catastrophe—today’s cryptography won’t be broken overnight. But the direction of travel is clear. Each improvement in hardware or algorithms reduces the gap between current capabilities and useful quantum cracking machines.

Second, viable defenses already exist. NIST has standardized several post-quantum cryptographic algorithms which are believed to be resistant to quantum attacks.

Technology companies have begun deploying these in hybrid modes: Google Chrome and Cloudflare, for example, already support post-quantum protections in some protocols and services.

Systems that rely heavily on elliptic-curve cryptography—including cryptocurrencies and many secure communication protocols—will need particular attention. Google’s recent work explicitly highlights the need to migrate blockchain systems to post-quantum schemes.

Finally, this is a two-front race. It is not enough to track progress in quantum hardware alone. Advances in algorithms and error correction can be just as important, and recent results show these improvements can significantly reduce the estimated cost of attacks.

Every new headline about reduced qubit counts or faster quantum algorithms should be understood for what it is: another step toward a future where today’s cryptographic assumptions no longer hold.

The only reliable defense is to move—deliberately but decisively—toward quantum-safe cryptography.

This article is republished from The Conversation under a Creative Commons license. Read the original article.

The post Quantum Computers Are Coming to Break Cryptography Faster Than Anyone Expected appeared first on SingularityHub.