Evil Fonts deceive a viewer by rendering a different letter than is actually on the disk. Evil Fonts can poison HTML, DOCX, PDFs, and anywhere else you can bring your own fonts. Works great in Windows corporate networks for bypassing security tooling, initial access through JavaScript free click fix (beats mitm web security tooling), and leaving traps around the network to harvest shells.
Imagine thinking you are copying whoami but what is actually on the disk is rm -rf \~
For the demos, copy and paste the HTML/DOCX to a notepad to remove the evil fonts. For the AI ones imagine your security tooling inspects the benign text on disk, but shows the obviously malicious extortion to the user.
Despite the popularity of Claude Code, Cursor, GitHub Copilot, and OpenAI Codex, developers have plenty of complaints about AI coding tools. So researchers affiliated with York University and the University of Calgary in Canada decided to sift through developers' concerns about LLM-based integrated development environments (LIDEs) by analyzing Reddit discussions for common themes. Their findings suggest that the builders of such tools failed to prioritize security and privacy, leaving developers to defend themselves. Gias Uddin, associate professor at York University and a co-author of the research, told The Register that these tools are still relatively new and are evolving rapidly, which creates pressure to add new capabilities. "Our study cannot say whether that pressure caused any particular problem, but it does show that many reported issues come from how these tools are designed and what access they are given, not simply from the underlying models," Uddin said. "In that sense, we believe prevention is better than cure; that is, security and privacy mechanisms should be built into the design before a tool is given broad access to a developer’s files, data, or systems." Uddin and co-authors Mostafijur Rahman Akhond, Md Afif Al Mamun, and Song Wang say they wanted to look beyond the known issues with AI-generated code at LLM-based tooling and how developers interact with it. They describe their findings in a preprint paper titled "'Impossible to hide secret …': Uncovering Security and Privacy Issues in LLM-native IDEs," accepted at the 41st IEEE/ACM International Conference on Automated Software Engineering (ASE), 2026. Starting from a set of 1.1 million Reddit posts, they identified 446 posts and more than 6,000 comments to develop a taxonomy of security and privacy issues associated with using these LIDEs for AI-assisted coding. "Our taxonomy reveals a broad range of developer-reported concerns, including unauthorized file operations, unsafe or unexpected code execution, triggering of destructive actions, opaque data flows, telemetry collection, and potential leakage of sensitive information through expanded context access," the authors state. Some 43.1 percent of the posts covering security-related issues involved unauthorized file operations. These involved LIDEs removing project directories or files without authorization (28.3 percent). Users also described AI tooling modifying files without explicit user consent (8.8 percent), as well as accessing content beyond the active workspace (5.7 percent). "In one severe case (1npqf2f), Claude Code executed chmod +x on scripts without consent (File Permission Changes 0.6%)," the paper recounts. "Although rare, such actions pose disproportionate security risks." Another set of posts describes operational safety issues arising from LIDE use, including impacts on production services. These accounted for 23.9 percent of security-related posts. Examples cited include reports of Replit removing a SaaS production database and Cursor deploying code to production despite an explicit directive not to do so. A third category of woes covers unsafe code generation (18.2 percent). This involves incidents like nine VirusTotal detections reported for Cursor-generated software and hallucination-driven code changes: "When using Cursor, I noticed that after more than 10 rounds of dialogue, it starts to hallucinate and secretly modify code outside the requirements…" Then there are the instances where these LIDEs ignored user instructions, allow lists, gates, permission settings, or .ignore files, which account for 16.5 percent of the security-related posts, as well as third-party tool integration risks (4.7 percent). As for privacy problems, these were mentioned in 194 posts and cover issues like lack of transparency (45.9 percent) – the absence of clear information about what data an LIDE collects, retains, transmits, uses for training, or exposes to administrators – and unauthorized data access (23.7 percent). Other privacy categories include privacy leakage violations (15.5 percent), unauthorized data collection and transmission (11.9 percent), and context integrity failures (8.8 percent), which refer to situations where "for example, a user of Claude Desktop reported receiving messages originating from another user’s session." Uddin said, "We don’t think developers are completely unaware of these issues, as we found ongoing discussions about security and privacy concerns across many of these tools. Still, people continue to adopt them because they can make development faster and easier. They are also making programming more accessible to a wider group of people, including those with little formal programming experience or limited knowledge of software security." Uddin said users cannot be expected to thoroughly understand which permissions are risky, which files need to be protected, or whether a tool is doing something it shouldn't. "That makes it even more important for tool makers to build security into the tools themselves, with safer defaults and safeguards that do not depend on the user being a security expert," he said. Even so, users of LIDEs are trying to manage the risks. The authors enumerate 13 mitigation strategies that developers have employed to get by. These fall into five general approaches: configuration management (33 percent); code governance (31 percent); data protection and privacy control (13 percent); isolation (13 percent); and external guidance (9 percent). Based on their findings, the authors offer six recommendations. They advise: directing LIDE makers to implement proper security and privacy controls; enforcing security and privacy guardrails at an architectural level; incorporating a verification layer in LIDEs to validate generated code against security and privacy standards; establishing a formal protocol for assessing the trustworthiness of third-party tools; integrating sensitive file protection; and implementing strict security as a default. "We believe secure defaults would be one of the most important improvements these tools could make," said Uddin. "Developers should not have to discover after something goes wrong that a tool had more access or freedom than they expected. "Our findings point to practical measures such as limiting access to sensitive files by default, requiring clear approval before consequential actions, isolating projects and conversations, and making it easier to see and review what the tool is doing. "Users should still have flexibility, but the safer option should be the starting point rather than something they have to configure themselves. In fact, developers from the Reddit posts in our study were already using many of these safeguards in ad hoc ways; we think several of them should be built into the tools and enabled by default." ®
Plus: A judge rules cell tower dumps unconstitutional, water utility hacks spread to a dozen states, a phishing email opens a missile-parts supplier’s inbox, and a ransomware boss gets 16 years.
Two security researchers bought cheap domains—including noreply.net and deleteduser.com—and set up email listening services. Hundreds of companies are sending them corporate secrets.
Write once, shell everywhere. Sun Microsystems didn't mean it like this.
Talk from today at DEF CON's Bug Bounty Village. Full technique catalog graded for distroless containers, an errno path oracle for black-box target fingerprinting, and three minimal-guessing techniques: bash fd/255, Rails schema_cache.yml deserialization, and a Node.js worker path overwrite without process restart.
Yes, given that the legacy SCT protocol has known security vulnerabilities such as sctphantom, the industry strongly recommends deprecating it and migrating to more secure modern standards to ensure system security.
After acknowledging last month that unreleased AI models committed what for human perpetrators would be computer crimes, OpenAI now says it cannot rule out the possibility that Astra, a pending model release not involved in its Hugging Face hack, might possess critical cyber capabilities. OpenAI in its Preparedness Framework [PDF] defines that term to mean "capabilities that present a meaningful risk of a qualitatively new threat vector for severe harm with no ready precedent," and notes that such capabilities "require safeguards even during the development of the covered system, irrespective of deployment plans." Noting, or perhaps boasting, that internal evaluations of Astra "indicate significant advancements in agentic coding and cybersecurity," OpenAI insists that this time, there will be security – something that also eluded Anthropic, Meta, and the UK's AI Security Institute during model testing. "We are implementing stricter security controls for higher-capability models and associated activities, including isolated testing environments, restricted network and tool access, enhanced model weight protections and encryption, additional monitoring and detection capabilities, and sandboxed execution," the AI biz declared on Friday. That may surprise those who expected such safeguards would already be in place. This comes with a promise to pause Astra testing internally where these security controls are absent and to provide recommendations to third-party testing partners about how to run high risk evaluations and workloads safely – knowledge that OpenAI itself might have found useful when its models pillaged Hugging Face. What's more, OpenAI intends to implement thought policing for Astra, at least in the pre-release stage. "We have implemented universal monitoring for risky actions and misalignment across all agentic applications of Astra, including training and evaluation," the company explained in its post. "Monitors evaluate the model's Chain of Thought and trigger a security response to review and interrupt high risk activity." We're told that OpenAI's commitment applies to internal usage and isn't necessarily an indication that chain-of-thought monitoring will be conducted during commercial operation. But other frontier models like Anthropic's Fable and Mythos have implemented stronger classifiers to reject interactions deemed risky and retain data even for commercial customers expecting zero data retention. Moving in the opposite direction, Anthropic on Friday said it is relaxing Fable refusals, or "fallbacks," to use the company's euphemism, so they don't happen as frequently for prompts involving biology. The concern has been that some vibe terrorist using the company's cash-burning, water squandering, grid taxing, content laundering service might do harm by convincing the model to emit chemical warfare instructions. To avoid that possibility, the Claudefather made the initial release of Fable all but useless for security researchers and biologists. Now that China-based AI firms have shown they can field competitive open-weight AI models for less than their US rivals, the need to remain competitive in the market appears to be tempering Anthropic's willingness to alienate potential customers by hobbling its best models. OpenAI isn't quite there yet. The ChatGPT maker argues, "We believe advanced cyber-capable models should help defenders identify and address vulnerabilities before attackers do." Believing that, however, won't make it so. Adversaries, whoever they may be, already have access to encryption and all sorts of weapons. OpenAI may believe that it can give favored nations and organizations exclusive access to its most capable models, but history suggests any such advantage cannot be maintained. Better to focus on building defenses than playing keepaway forever. ®
With at least 12 US states’ water systems having been hacked - most likely by Iran - we have to get better at cyber defense, according to retired General and Ex-NSA chief Paul Nakasone, who was speaking to reporters at DEF CON. “We have to have higher standards,” Nakasone said. “These PLCs should not be connected to the internet.” In late July, the FBI said it was investigating attacks conducted by “malicious cyber actors” targeting operational technology devices, including programmable logic controllers (PLCs). Iran-linked crews have targeted these devices, which monitor sensor data like tank levels, and can turn pumps on and off, for years. Some private-sector security researchers say that they suspect Iranian intruders are behind the recent cyberattacks disrupting water and wastewater facilities. “I'd be shocked if it's not Iran,” Halcyon Ransomware Research Center SVP Cynthia Kaiser told The Register at DEF CON on Friday. “It's almost certain it's Iran.” Neither the FBI nor anyone in the Trump administration, however, has officially blamed Iran. Nakasone said he believes that the feds are “taking a measured approach” to attribution. “But I see an actor here that has certainly shown a history of being able to do this,” he added, referring to earlier Iranian cyberattacks targeting water facilities’ PLCs. “They certainly have the capability,” Nakasone said. “There's an intent … we're in conflict with Iran.” US water systems present a massive attack surface across disparate facilities that are historically underfunded and have limited IT staff, and sometimes no dedicated cybersecurity employees. “We have to think differently about how we defend it,” Nakasone said. “Let's talk about the attack surface that we're looking at right now. We’ve got 50,000 different water municipalities in the United States, 90 percent of our water comes from these 50,000.” Defending these water systems requires partnerships, he added, pointing to DEF CON Franklin, a project launched two years ago at the annual event with hackers volunteering their time and talent to help secure water facilities. Nakasone also serves as founding director of Vanderbilt University’s Institute of National Security, and its Wicked Problems Lab. He's also working on Project Chimera, a cybersecurity platform being developed by academics and cybersecurity practitioners, and built on open-source technologies to boost critical infrastructure resilience. “How do you defend better? You defend with a series of partners, in a much more involved approach than we have right now,” Nakasone said.®
The meetingscollection has no tenant isolation. Any authenticated tl;dv user can query every meeting across every account on the platform. Each meeting record hands you the creator's email address, the conference ID (which is a joinable Google Meet or Teams room), the provider, the recording status, and timestamps.
I queried the Firestore meetings collection and saw there were 181,874 meeting records belonging to 84,312 unique users across 35,003 email domains.
Ransomware attacks jumped nearly 20 percent in July, with UK firm Comparitech counting 799 incidents, up from 668 in June. Of those, 51 had been confirmed by victims. The tally makes July the second-busiest month of the year for ransomware, behind March, albeit just barely, when the firm recorded 805 attacks. The most interesting data after this surging month of attacks is the targets: While news of widespread cyberattacks targeting water infrastructure in the United States may be dominating security headlines lately, those attacks aren’t ransomware, and ransomware attacks on utility companies were actually down 44 percent last month. In addition to a decline in attacks on utilities, legal firms and government agencies also became less attractive targets, with attacks on those sectors down 31 percent and 11 percent, respectively, Comparitech said. On the other hand, ransomware attacks increased most heavily in July against finance companies, tech firms, pharmaceutical companies and medical billers, and the education sector, with rates up 71 percent, 62 percent, 46 percent and 44 percent, respectively. Those numbers should come as no surprise given what pentesting firm DeepStrike reported about the most frequent payers of ransomware: Manufacturing, education, healthcare, and financial sector firms are the most likely to pay out a ransom, the firm says, with even the least likely (finance) still paying ransoms 51 percent of the time. Ripe targets, in other words. The United States was the most-targeted country, with 322 of the 799 attacks recorded last month, Comparitech said. Germany, in second place, saw just 40 incidents. As for who’s doing the dastardly deeds, there’s a familiar name in the mix, but they’re competing with a relative newcomer who has quickly become prolific. Qilin, the ransomware gang behind the 2024 attack on pathology provider Synnovis that disrupted NHS services in the UK, claimed 125 ransomware victims in July. The Gentlemen, a relative newcomer that has quickly become one of the most prolific ransomware operations and earlier this year claimed responsibility for an attack on UK software consultancy Adaptavist Group, led July with 135 claimed victims. Between them, the two gangs accounted for nearly 33 percent of attacks logged last month. As for how the crims keep getting in, Comparitech provided no information on ingress routes, but given what we know of the top-tier gangs, it could be simply using stolen credentials, as Trend Micro said of The Gentlemen’s methodology, or it could be abuse of zero-day vulnerabilities, as Qilin told The Register it abused to break into Synnovis in June of 2024. Either way, the takeaway is the same: Ensure employees are using a second secure factor to log in, keep systems updated, and be sure you’re making regular backups. All eyes may be on what AI is doing to the security landscape, but old-school threats aren’t going away. ®
ByteRay researchers have published a blog on a set of vulnerabilities they are calling TrustFall, and the findings land hard for any company that treats the Trusted Execution Environment as the part of a device you do not have to worry about.
OP-TEE is the walled-off Secure World that phones, TVs, cars, and industrial gear lean on to guard keys, DRM, and identity, and the whole point of paying for that hardware isolation is the promise that even a compromised operating system cannot reach inside.
TrustFall shows that promise was not as solid as buyers assumed. The researchers found several flaws that let the untrusted side reach into or knock over the Secure World, which is exactly the outcome the design exists to prevent. The bugs have since been fixed upstream, so patched builds are available, but the uncomfortable takeaway for vendors is that the vault they were told to trust had a way in, and "it runs in the TEE" is no longer an answer on its own.
N-able has confirmed attackers exploiting an N-central zero-day made it into customer networks, as the vendor pushes out a second mandatory hotfix just days after the first. The security shop published an update on Thursday detailing what happened after attackers exploited CVE-2026-18577, the critical N-central flaw that can hand an unauthenticated attacker administrative access to the remote monitoring and management platform. According to N-able, attackers exploited vulnerable N-central servers remotely, then used the platform's Take Control feature to connect to systems inside the environments being managed through them. Once there, they registered a new Cloudflare Tunnel service to keep their foothold even after being booted from the N-central server – behavior that Huntress had already observed in the wild. N-able has now confirmed that its own investigation found the same activity, and says a "limited number" of customers were affected. It hasn't said how many customers that means, how many downstream systems attackers reached, or what they did once they had established persistent access. N-Able didn’t answer these questions when asked by The Register, instead providing a statement saying it is “proactively expanding protections in response to ongoing monitoring of threat actors as they evolve their attack techniques.” The firm’s limited disclosure comes alongside Hotfix 2, version 2026.3.1.10, which N-able says customers running N-central on-premises must install immediately – including those that already installed the first emergency fix released on August 2. "This is not a duplicate of our previous communication," N-able warned. "Hotfix 2 is required, even if you already applied the earlier hotfix." The company says the new update supersedes Hotfix 1 and adds further hardening measures as it monitors threat actors and watches them "evolve their attack techniques." Exactly what prompted the second round of defenses isn't clear. N-able hasn't said whether attackers found a way around Hotfix 1, and its latest description says the exploited vulnerability affected N-central servers running versions prior to 2026.3.1.7, the first hotfix. Hosted N-central environments have already received the latest mitigations, according to the vendor. N-able first became aware of the attacks on July 31, after its Adlumin managed detection and response service picked up suspicious activity at a customer. Further digging uncovered a zero-day being actively exploited against an N-central server. CVE-2026-18577 was subsequently disclosed, and the first hotfix was released on August 2. CISA added the bug to its Known Exploited Vulnerabilities catalog and gave US federal agencies until August 6 to fix it – an unusually short three-day deadline reserved for vulnerabilities the agency considers an urgent risk. N-central is particularly attractive territory for attackers because managed service providers use the software to administer large numbers of customer systems from one place. Compromising the management platform can therefore provide a route into machines belonging to the MSP's customers rather than leaving attackers stuck on the original server. Huntress previously described successful exploitation as giving an attacker the same level of N-central access normally reserved for trusted network operations and engineering staff. Its investigation found attackers using that access to launch remote-control sessions against managed endpoints. N-able has now published 10 IP addresses it says were used in the attacks and released a service template that customers can use to hunt for known indicators of compromise on Windows endpoints. The company is warning customers not to take a clean scan as an all-clear, however, saying the tool only checks for indicators identified so far and that more may emerge as its investigation continues. For anyone running N-central on-premises, the immediate instruction is pretty straightforward: install Hotfix 2, even if Hotfix 1 is already in place. ®
Two MIT researchers will present a new speculative execution attack at Black Hat that uses precisely timed interrupts to bypass defenses against Spectre v2. Daniël Trujillo and Mengjia Yan of MIT's Computer Science and Artificial Intelligence Laboratory (CSAIL) shared their paper [PDF] with The Register ahead of publication. Their attack targets mitigations designed to neutralize potentially hostile branch predictor states before sensitive code runs. Such neutralization is an important defense against Spectre-style attacks. Depending on the mitigation, the processor or operating system isolates, clears, or safely retrains relevant predictor state when entering privileged code or shortly before a protected branch executes. Different chipmakers deploy neutralization mitigations slightly differently. Intel's eIBRS sanitizes branch predictors upon context switch, while AMD's Safe RET, introduced after the Inception attack Trujillo co-authored in 2023, focuses on the point immediately before a protected branch is executed. Trujillo and Yan refer to these as entry neutralization and in-place neutralization respectively. Crucially, the two classes share the same underlying assumption that attackers cannot alter branch predictor states within what's known as a "post-neutralization window" – the period between state neutralization and the branch predictor being used. The defense here relies on the assumption that everything between the point of neutralization and the usage by a victim branch is safe. Trujillo and Yan's attack shows how attackers can re-poison the branch predictor during the post-neutralization window. The researchers call the new class of attack TONTOU, for Time-of-Neutralization to Time-of-Use. They demonstrated that an attacker can exploit the post-neutralization window to re-poison branch predictor state on recent AMD and Intel processors. To do this, they developed an attack primitive called "interrupt injection." An unprivileged program schedules high-frequency timer interrupts in the hope that one will land during the often tiny post-neutralization window. Being able to trigger interrupts during the post-neutralization window allows attackers to divert control flow so that an interrupt handler executes after the sanitization phase and before the victim branch is used. The interrupt handler can then re-poison predictor structures such as the return stack buffer (RSB) or branch history buffer (BHB), causing a protected branch to speculatively jump to a disclosure gadget that leaks kernel data through a side channel. Practical attacks The researchers said that their tests showed the TONTOU attacks worked on both Intel and AMD-based Linux systems. They tested TONTOU on Intel Cascade Lake Refresh and Arrow Lake processors and AMD Zen 2 and Zen 4 chips. The researchers built a complete end-to-end exploit only for Zen 2, largely because the Intel attack requires specific software conditions. Speculative side-channel attacks remain difficult to pull off, and you're more likely to fall victim to ransomware than Spectre in the real world. Another serious caveat is that each end-to-end attempt took about 18 minutes, and you can see a sped-up version via the video Trujillo posted to YouTube. Trujillo and Yan identified the exact point at which they needed to inject their interruptions to poison the RSB, and through a series of attacks broke Linux's kernel address space layout randomization (KASLR), which allowed them to locate specific secrets such as etc/shadow, which contains the root password hash. Across ten total runs, the researchers were able to break KASLR every time, although they were only able to successfully locate and leak the contents of etc/shadow in five of these. "It's definitely not a simple attack, but we show that it's practical with our end-to-end exploit on AMD Zen 2," Trujillo told The Register. "Our demonstration does not assume anything special from the system: we use a stock Linux kernel version, no inserted modules, and all default mitigations. Any time you'd execute unprivileged code with timer availability on a system while sharing the kernel with a victim, this attack would be an issue. "For example, multi-tenant container platforms would fall in this category, allowing ordinary user space programs to leak memory from the shared kernel." The researchers hope that their work will inspire further investigations into interrupt injections and TONTOU attacks, and to help develop more robust mitigations against Spectre-style exploits. They engaged Intel, Arm, and AMD after gathering their results, but only the latter committed to address the issue via kernel patches. Intel told the pair that it won't be working up any other mitigations since real-world exploits are subject to too many factors, such as the availability of disclosure gadgets, although it awarded a prize from its bug bounty program in the hundreds of dollars. Arm said TONTOU's interrupt injections fall under "passive leakage," which it does not "actively protect against." ®
Login
