I wanted to build an HTML file with Claude. And it started a Node server to open it. And there was a Directory Traversal as well there. Always review what agents / LLMs do
The AI research centre at Torrens University Australia has helped produce a review of 110 studies on digital twins and IIoT security.
What were the main takeaways? They have found that DTs are shifting away from passive monitoring to being a part of the defence architecture.
One of the biggest weak points they found was in legacy sensors with low bandwidth. In these situations, there is a lag before the digital twin reflects a real-world change, and that lag is where attacks tend to slip in.
Would be interested to hear your thoughts! Has anyone here dealt with that sync-gap problem on older hardware?
Recently, I saw someone selling a well-known second-hand market in China. Except for some functions that need to be connected to networking, the 4th generation is used normally. However, because AXON is not in the Chinese market, most of them purchase the activated version from eBay and then reverse. Will such a problem lead to the body camera video of some American enterprises and some unpublished videos of the police will be leaked. Then he sells these body3 and 4th generations at prices ranging from 1,000 dollars and about 1,500 US dollars respectively, and gives a unique software to read and delete it. The question is whether it is feasible or not, but it is not fake to see the real shot.
Family of 11 same-codebase extensions (ChatGPT/Claude/Gemini/etc), ~5.5k users on the main one. Sold as local-only: the store listing says "No uploads to external servers," "Everything processed locally," "No tracking or telemetry."
Observed in the tested version:
PDF export POSTs the full conversation to the developer's Cloud Run backend. A local renderer is bundled but only runs as a fallback.
Markdown/Text/JSON exports beacon title + source URL to /api/usage. The title is derived from your first message, so it can contain chat content.
Every request carries an X-Client-ID in chrome.storage.sync, so it follows you across machines.
I wrote this after spending an unreasonable amount of time making CET-compliant callstack spoofing work end-to-end on hardware with Intel CET enabled.
The technique combines three primitives: thread pool execution for a clean stack base, enum callback trampolining for a real signed mid-stack frame, and indirect syscalls.
The actual contribution is the CET compliance mechanism: a jmp-based context switch combined with direct shadow stack pointer reconciliation via RDSSPQ/INCSSPQ, without touching unwind metadata. Different approach from BYOUD.
The Cybersecurity and Infrastructure Security Agency (CISA) has issued a postmortem on a recent data leak in which a contractor published dozens of internal CISA credentials β including AWS Govcloud keys β in a public GitHub repository for almost six months before being notified by KrebsOnSecurity. Experts say the gaps identified in the agencyβs initial response provide important lessons that all security teams should absorb.
On May 15, 2026, the security firm GitGuardian asked for help in notifying CISA about the existence of a public GitHub repository called βPrivate CISAβ that included 844 MB of sensitive CISA-related data. One of the exposed files, titled βimportantAWStokens,β included the administrative credentials to three Amazon AWS GovCloud servers. Another file β βAWS-Workspace-Firefox-Passwords.csvβ β listed plaintext usernames and passwords for dozens of internal CISA systems.
CISA quickly acknowledged our initial alert, but took more than 48 hours to invalidate the AWS keys and many other important secrets leaked in the GitHub repo. In its report on the data leak, CISA said the complexities of the agencyβs systems and interconnections with federal and industry partners caused its key rotation to take longer than anticipated.
βDrawing on this experience, CISA encourages others to maintain mature and well-tested key management capabilities,β the report notes.
CISA also admitted it can do better when it comes to responding to security incident notifications from external parties. The postmortem stresses that clear and distinct reporting channels are essential to ensure that incidents affecting the organization itself are handled differently from those involving its products or customers.
βIn CISAβs case, these channels were not well defined, leading the security researcher to try multiple avenues β including emailing the contractor, submitting through CISAβs vulnerability disclosure platform (which is intended for vulnerabilities impacting the broader cybersecurity community), and ultimately involving a reporter,β reads the analysis written by Preston Werntz and Brad Libbey, the acting chief information officer and acting chief information security officer at CISA, respectively.
CISA said it is refining its reporting channels to make them easier and faster for researchers. βAdditionally, while many researchers rely on the security.txt file, organizations can ensure clarity by publishing reporting instructions in multiple prominent locations,β the CISA authors wrote.
Guillaume Valadon, the GitGuardian researcher who first contacted KrebsOnSecurity about the exposed CISA credentials, said CISA ignored nine automated alerts about the exposed credentials prior to our notification on May 15. Valadonβs company constantly scans public code repositories at GitHub and elsewhere for exposed secrets, automatically alerting the offending accounts of any apparent sensitive data exposures.
βLetting nine notification emails go unanswered is how a one-day incident becomes a six-month exposure,β Valadon wrote in an analysis of CISAβs report. βMake it trivial to report a leak about you, not just about your products. The person reporting a leak to you is not the threat. Publish a security.txt, but do not stop there. Put reporting instructions in several prominent places, and make sure a report about your own infrastructure does not land in a product-bug queue.β
The reportβs authors also emphasized the importance of continuously scanning public code repositories like GitHub for exposed secrets, and said CISA has since rotated all secrets and created an action plan to improve management of developer secrets and to better monitor for them going forward.
The report notes that while CISA had developed a playbook for responding to cybersecurity incidents, that playbook somehow didnβt include what to do in situations involving GitHub or other cloud services. Valadon said the report validates the need to scan continuously β not just quarterly β for exposed secrets.
βThe Private-CISA repository sat public for six months,β Valadon wrote. βContinuous monitoring of public GitHub surfaced it. Comprehensive internal scanning could have caught the plaintext passwords and committed backups long before they left the building.β
CISA gave itself passing grades on several areas of security preparedness that it said helped the agency gauge the scope and impact of the exposed secrets, including enhanced logging capabilities, and the adoption of zero-trust principles in both its production and development systems. CISA said those detailed logs allowed it to show that no customer or mission data was exposed, and that the leaked credentials were not used outside of CISAβs environments. The agency said the contractor who exposed the secrets had their system access revoked.
Valadon reckons the biggest takeaway is the CISA postmortem itself, and praised the agency for being transparent about what worked and what didnβt.
βTo my knowledge, it is also the first time a national cybersecurity agency has publicly advocated for secrets scanning and for simplifying relations with security researchers,β Valadon wrote. βThat is exactly the incident communication we should expect from every organization.β
The SFPDβs exposure of hours of videos from drone platform Skydio reveals how broadly itβs watching the city from aboveβand how the results can spill online.
Plus: The Pentagon is training amateurs to become part of its hacker army, a Flock license plate reader error led to cops surrounding a car reviewer, and more.
Uptime, pulse checks, execution time, response time. Weβve always treated these as health metrics. They tell us whether a system is alive, responsive, and performing as expected. But what if theyβre also security metrics?
That idea isnβt entirely new. At the network layer, covert timing channels, beaconing detection, and behavioral baselining have shown us for decades that the intervals between events matter. Attackers have long understood that rhythm carries information. More recently, researchers have demonstrated timing side-channel attacks against LLMs, using cache latency to infer private prompts and token cadence to fingerprint model outputs.
What I find interesting is the imbalance. Most of the research asks, βHow can timing be exploited?β Very little asks, βHow can timing help us defend?β
A 2026 systematic survey of LLM-agent security identifies temporal anomaly detection infrastructure as an open research gap, noting that current agent deployment frameworks donβt even support the behavioral baselines such an approach would require. Even then, the discussion largely focuses on session-level behavior. The rhythm within a single execution, the space between observable events, remains largely unexplored.
Maybe time isnβt just metadata, maybe itβs another dimension of observability that weβve been overlooking.
Time tells you duration and speed. But read carefully, it also reveals location, choke points, and absences, the things that didnβt happen when they should have.
Iβve started exploring this in my own observability work, measuring behavioral changes & entropy across inter-arrival intervals and treating rhythm as signal rather than noise to smooth away.
Curious to know who else is working on the defensive side of temporal behavior, especially for agentic systems or any thoughts or opinions on this topic.
Reference: βA Systematic Survey of Security Threats and Defenses in LLM-Based AI Agents: A Layered Attack Surface Framework,β arXiv:2604.23338 (2026). https://arxiv.org/abs/2604.23338
Cyber Threat Intelligence (CTI) has traditionally attributed attacks through Tactics, Techniques and Procedures (TTPs).
In this paper we evaluate whether that assumption still holds when AI agents are explicitly configured to emulate known threat groups.
We configured AI agents to reproduce the behavior of APT28, APT29, APT41, APT44 and Lazarus inside enterprise and military cyber ranges.
Our results suggest that sufficiently capable AI agents can reproduce TTP patterns closely enough to make attribution based solely on behavioral evidence significantly more difficult.
We'd be interested in feedback from practitioners working on CTI, attribution or adversary emulation.
Login/r/netsec - Information Security News & Discussion
