Today, in most countries around the world, virtually every reasonably large city is packed with video cameras. On the one hand, the idea, of course, is to “keep us safe”: to monitor security in the streets, improve road safety and enforce traffic rules, and so on. But there’s the other side of the coin — ubiquitous video surveillance creates both privacy risks and opportunities for unauthorized surveillance We’ve repeatedly posted on our blog about how to protect yourself from surveillance involving IP cameras.
There’s another problem, too: relying too heavily on video surveillance systems can also be dangerous. If your cameras aren’t adequately cyber-secure, attackers may be able to disable them remotely to be able to then enter physical areas supposedly protected by video surveillance without being detected. This issue is especially relevant to home and privately managed surveillance systems — large companies generally do a better job of securing their devices (although there are exceptions there as well).
Disabling or replacing a camera feed is an almost obligatory plot device in heist movies. But unfortunately, this isn’t just a screenwriter’s invention: our recent research uncovered a vulnerability that makes it possible to remotely disable IP cameras made by Intelbras — a popular camera manufacturer. Read on to learn what the problem is, and how to protect your surveillance systems; a detailed technical analysis of the vulnerability is available on our expert blog, Securelist.
When an update does more harm than good
A surveillance camera is essentially a fully-fledged mini-computer, and its firmware needs to be updated regularly. In this case, however, the vulnerability was hidden in the firmware update procedure itself.
Intelbras provides firmware update files on its official website. The firmware can be updated manually from an SD card, or over the local network via the web interface or mobile app. However, during a firmware update, the camera neither required (past tense; a patch has since been issued – see below) authentication nor validated the firmware file before starting the update. As a result, anyone connected to the same Wi-Fi network as the camera could send it an update request. When an update is initiated, the camera reboots, taking it offline for about a minute before it becomes available again. But if the requests are sent repeatedly in a loop, the camera can be kept offline indefinitely.
We investigated this vulnerability on an Intelbras iM3 C (iM3B-C) camera running firmware version v240927 — the latest available at the time of our research. The iM3 C is a smart Full-HD Wi-Fi camera designed for both home surveillance and as a baby monitor. According to Intelbras, the firmware for the iM3 C is also compatible with the iMX C, iM4 C, iM5 SC, iME 360 C, and iM7+ FC models.
Intelbras iM3 C smart Wi-Fi camera used for the investigation. Its firmware is also compatible with the iMX C, iM4 C, iM5 SC, iME 360 C, and iM7+ FC models. Source
This vulnerability has a medium severity rating. However, because of the large number of potentially affected users, the impact of successful exploitation could be significant. Intelbras Mibo Smart — Intelbras’s app for setting up and managing these camera models — has been downloaded more than four million times, with most of its users based in Brazil and elsewhere in Latin America.
How to secure your cameras and other smart devices
First and foremost, all Intelbras owners should update their camera firmware as soon as possible — and continue to do so regularly. More generally, it’s a good idea to secure your smart-home infrastructure in advance to reduce the risk posed by other potential vulnerabilities.
One of the simplest yet most important steps is to change the default settings on both your smart devices and your home network. Be sure to replace the factory-default passwords on all smart devices and on your router — default username/password combinations such as admin/admin or root/admin provide no meaningful protection.
Protect your home Wi-Fi with a strong password; otherwise, attackers could easily gain access to your local network.
Disable WPS on your router. WPS is designed to simplify network setup and authentication: you can connect by pressing dedicated buttons on the router and respective device, or by entering an eight-digit PIN. The problem is that this PIN can be brute-forced relatively easily, allowing an attacker to recover the key to your Wi-Fi network fairly quickly.
Use a strong, unique password for every account that can be used to manage your smart devices through official apps or websites. Where possible, enable two-factor authentication (2FA); the most secure option is generally to use one-time codes generated by authenticator apps. For generating and storing passwords, as well as creating one-time codes, it’s most convenient to use a password manager.
Put your IP cameras and other smart devices on a separate Wi-Fi network — isolating them from phones, laptops, tablets, NAS devices, and so on. Most modern routers can create at least two Wi-Fi networks (a primary and a guest network). Use the guest network for smart-home devices, but make sure it’s protected with a strong password. If your router supports multiple Wi-Fi networks, consider putting the cameras on a dedicated network of their own. That way, even if the cameras are compromised, attackers won’t be able to reach your other devices.
Use Smart Home Monitor, available in Kaspersky Plus and Kaspersky Premium. This feature shows all devices connected to your home network, lets you check their security status, and alerts you if an unknown device joins your home Wi-Fi.
More camera-security and smart-device tips and stories:
If your answer to question #1 is anything but a yes, please (re-)read “Defense in Depth” by Phil Venables. I quoted it in the cloud post, and it turns out to be even more useful for AI. Phil’s bottom line is that DiD is “about the linkage and collected effect of controls,” not arbitrary stacking. He also offers principles for placing controls, and three of them become critical with AI:
Positive duplication. Duplicate controls should not share one common cause of failure, so use different teams, vendors, or designs on a critical path.
Full complementarity. Every preventive control should have a detective control that checks the prevention actually worked.
Control pressure. Watch at which layer attacks are actually stopped; rising pressure deeper in the stack means it is time for redesign.
(and, again, no, defense in depth does not mean “just use more than one security control” … or, in 2026, “just use more than one LLM”)
Three schools of thought (again)
With cloud, I found three schools of thought. With AI, I found … three schools of thought. Some patterns are fractal, just like Phil says DiD should be (“Defense in depth should also be fractal”)…
“Bolt-on DiD”: AI DiD is classic DiD plus one new AI layer, firewall sandwich with AI mayo, basically (or: “AI-oli sauce” as somebody wisely quipped)
“DiD is dead”: AI DiD does not exist and does not matter. AI means “everything changes.” “AI can hack everything” camp lives here.
“AI-native DiD”: it exists for sure, you just need to discover it for yourself …
The first view is basically “lift and shift DiD,” AI edition. Take your network, host, app, data, and D&R layers, then add “a prompt firewall” in front of the model. Bam! The layer “M” is handled too. Uhu, yeah, right … This may be “correct” if your AI use is a chatbot answering FAQ questions with no data access and no tools (hi 2022 … bye 2023). It is almost certainly wrong the moment an agent can read your mail, call an API, and push code. The new layer was bolted on, but the old layers were never told that a new kind of principal now walks among them.
The second view comes in two flavors. The defender-pessimist flavor says prompt injection is unsolvable, so securing agents is futile. The attacker-pessimist flavor says AI attackers find and exploit bugs faster than we patch, so layers no longer matter at all (I particularly disdain these ones, if you care to hear it). A vendor-flavored variant says “only AI can fight AI,” so just buy the AI and stop thinking about layers. Intuitively, but also rationally, I know this camp is wrong. “This layer is imperfect” has been true of every layer since the first firewall. Imperfect layers are the entire reason for DiD, not an argument against it!
Finally, the third view is … well, still a bit of a mystery. Let’s try to discover it together, again!
What do we know for sure?
Now for the fun part! Let’s check what we know for sure so far. Two general points first:
DiD almost certainly matters more with AI, not less. More autonomy, more speed, and more probabilistic components all mean more chances for any single layer to fail.
DiD is still about layers of controls and interlocking controls within each layer, both technical and procedural. Nothing about AI repeals this; it just stress-tests it really well.
At this stage, I hope nobody is throwing a chair at the monitor in frustration. We are good so far, right?
When AI is the thing you defend
First, AI DiD gets married to a new shared responsibility model. In cloud, the provider owned some layers. With AI, the model provider owns some layers too (safety training, abuse monitoring), while you own the context, the tools, the data, and the agent’s permissions. Know where the line is, since that line is where layers silently go missing. Many of the cloud truths and frustrations apply here. Mostly frustrations, natch.
Stacked similar models are less depth than you think. A guard LLM watching your main LLM sounds like two layers. But researchers have argued that guard models often share the same statistical failure modes as the agents they monitor. Yes, “diversity of defense” is an ancient idea — some of us are old enough to remember arguing about dual-vendor AV stacks! What’s new here is why AI layers correlate. The nastiest attacks (clever role-play, indirect prompt injection buried in a Jira ticket) don’t exploit a coding bug; they exploit the exact thing every LLM is trained to do: follow plausible instructions. Swapping Model Vendor A for Model Vendor B doesn’t fix a shared objective. The math is simple: two layers that each stop 95% of attacks give you 99.75% only if they fail independently.
So count correlated LLM layers as partial layers at best. And here is the practical twist: diversity of the question matters more than diversity of the model. A narrow check asking “is this tool call within policy?” is a genuinely different layer from a general model asking “is this prompt malicious?” So, don’t laugh at “guardian LLM”, but also don’t assume that “guardian LLM” is a wall, more of an attack poodle…
The model is probabilistic, so the agent harness must be deterministic — split across time. In the cloud post, I said IAM plays an oversized role, so you need IAM-independent controls. With AI, the context window plays the oversized role, because everything in it can be attacker-influenced (a web page, an email, a doc, a tool result). So you need security invariants outside the model’s context window that hold even when the LLM is 100% socially engineered: scoped credentials, tool allowlists, egress restrictions, sandboxes (as a layer, not as THE solution!), transaction limits, etc.
My favorite idea here: frame modern AI DiD across time: put synchronous, zero-latency deterministic gates strictly under irreversible actions (moving money, dropping tables, sending data externally, changing IAM permissions), and use asynchronous, out-of-band AI supervision for everything else — watching telemetry in parallel and ready to trip a circuit breaker if a session goes off the rails. Put synchronous friction everywhere, and the business will happily route around you with shadow agents … leaving you with exactly zero layers.
Defend the verbs, not the words. The set of possible malicious inputs is effectively infinite; the set of actions an agent can take is not (it can get large for “fat” agents). So depth shifts from filtering prompts to governing actions: what this agent may call, with what identity, on what data, and how reversibly. Phil recently called this going from “shift left” to “shift down”, pushing controls into the platform so agents inherit them. Is “agent identity” a new layer or a sublayer within IAM? Is the tool/MCP layer a new layer? I genuinely don’t know yet, just as I didn’t know whether the cloud org boundary was one.
Every guardrail needs a detective twin, and mistakes count too. Phil’s full complementarity says each preventive control needs a detective control checking that it actually works. For agents: log every tool call and alert on actions that should never happen if the guardrail held. And remember my cloud post’s ending, that DiD must cover configuration mistakes, not just threats. An agent that “helpfully” deletes a production table is a configuration mistake at machine speed. If one confused agent causes a breach, DiD was absolutely missing. Finally, a human approval is only a layer if the approver isn’t clicking “yes” 300 times a day. Fewer, better gates beat many gates.
When AI is attacking you
After unprompted II conference, I can say that things are really fun here in this section.
The time layers buy at the edge is collapsing. This is NOT “DiD is dead”, but this is where it takes a good, heavy slap, yet still survives. Classic DiD quietly assumes that each layer delays the attacker long enough for you to notice and respond. For example, “just patch it” is still a layer, but it’s getting dangerously thin (unless you VulnOps, I guess). Here is the catch, though: AI massively accelerated recon, bug hunting, and exploit weaponization at the edge, more than it accelerates post-compromise lateral movement — as of today! Once inside your environment, an AI attacker still needs credentials, still trips identity detections, and still touches systems that emit logs.
Probabilistic layers get brute-forced. An AI-armed attacker can try a thousand variants cheaply. Any layer that “usually catches it” will eventually be bypassed by someone who can afford to retry. In Phil’s terms, expect control pressure to shift deeper into your stack. The design implication is clear: harden the edge as much as you can, and invest in containment behind it: blast radius, segmentation, fast+good (sorry, do need both) detection, and fast recovery.
Some “boring” layers are back in fashion. If prevention at the edge gets thinner, the layers that limit what happens after compromise matter more: egress control, internal segmentation (I like to call it “mini-segmentation”, not as small as micro, but pretty granular anyway), immutable infrastructure, etc. (Yes, I now work at Cisco, so feel free to discount this point by 20%. But I believed it before I joined!)
When AI is defending you
Your defensive AI is a new layer and a new single point of failure. If the same model (or vendor) sits in your detection, triage, and response layers, every alert passes through one model’s judgment, which is a hidden common cause across all three. Positive duplication applies here too! The fix is not necessarily two vendors; remember “diversity of the question.” This is not “replace Firewall Vendor A + Firewall Vendor B” with “LLM Vendor A + LLM Vendor B”! For example, let one model triage, and let a different, narrow detector sample-audit what it closed. Also, a SOC agent with response permissions is a privileged identity, and its inputs are logs and alerts … some of which the attacker writes. Defensive agents need DiD as much as any other agent! Over-reliance is a thing.
AI moves the cost of depth from tuning to validation. Historically, every new layer cost precious SOC analyst blood and sweat to tune, triage, and maintain — which is why so many enterprises only had “DiD on paper.” AI in your SOC can genuinely cut that tuning toil. Free lunch? Of course not! The cost doesn’t vanish; it migrates. Instead of babysitting brittle detection rules, you now spend cycles auditing the AI’s reasoning, testing its prompts, and catching the moment an autonomous tier-1 agent confidently auto-closes a real breach. Validation never goes to zero for a probabilistic layer, so your SOC’s AI needs its own detective control (full complementarity again).
So, where are we, so far
In one table
DiD skimmable
So, where to next?
So, is “AI-native DiD” still a mystery? Less of one, I think. If I had to compress it into one line: AI makes your layers more correlated and your edge slower than the attacker, so design for correlated failure and for speed. In practice, that means synchronous deterministic gates in the agent harness for irreversible actions, asynchronous out-of-band AI supervision for everything else, diversity of the question rather than just of the model, and more value placed on containment and recovery.
Philosophizing about layers is fun, but what do you actually do on Monday morning? If you want to move from “Bolt-on DiD” to “AI-native DiD,” start with these:
Correlated layers & the agent harness: inventory which of your agents’ actions are irreversible (money, deletion, external sends, permission changes), put a synchronous deterministic gate on each, and move heavy AI supervision out-of-band.
Time at the edge: measure how long it takes you to patch or shield your internet-facing stack after a critical disclosure. Compare that with how fast exploitation started during, ahem, recent weeks. If the gap scares you, fund containment behind the edge.
Ah, and please don’t confuse “deterministic” with, well, non-deterministic controls :-) Is model alignment a layer too? I don’t know, probably “weak yes” from me here.
Phil ended his post by saying it was meant to stimulate others to do more work on DiD. Three years after my cloud post, I am still taking him up on it. This time, though, I suspect the answer will come from practitioners who are already running agents in production, not from people like me thinking out loud on a blog…
Certificates both protect TLS connections and digitally sign applications, and forged ones turn up in real-world attacks from time to time. We’ve seen forged or stolen certificates abused by the DarkHotel APT and the Flame malware, and in 2011 we saw attack attempts after the certificate authority Comodo was compromised. Pulling off this trick usually takes serious expertise. But attacking eMudhra certificates in 2026 doesn’t take much effort at all. An attacker just has to guess a number from 1 to 255. Private keys for intermediate certificate authorities are normally gigantic numbers. But in this case, eight of them were the following: 4, 56, 66, 115, 155, 156, 230, and 237. They could be guessed using the public keys (available in public certificates) in under a second. As a result, a hypothetical attacker could issue certificates for anything by signing them with one of the compromised private keys.
Six of these keys were meant for issuing TLS certificates, and the other two were for code signing. All eight intermediate certificate authorities (CAs) were also cross-signed by the Sectigo CA. This means clients with different trust chains could trust a forged certificate.
The major browsers have already blocked the dangerous certificate chains. But IT and security teams still need to assess and remediate the risk in many other systems across their organizations. Scripts for scheduled data-processing, corporate NGFWs, monitoring servers, applications with built-in certificate stores, and devices that don’t get regular updates may accept forged certificates and be vulnerable to man-in-the-middle (MitM) attacks. The keys needed for this are already built into publicly available interception tools.
Timeline of the eMudhra certificate authority incident
The problematic keys came from a batch of 24 intermediate CAs that eMudhra created on April 30, 2025. Instead of cryptographically random values for a 384-bit elliptic curve, eight of the keys turned out to be small numbers. According to eMudhra’s own description, a “key wrap/unwrap step” during key generation created a second, weak set of keys. Because keys are created and stored in a dedicated device called a hardware security module (HSM), a weak key is hard to notice on its own. It’s still unclear what error caused the keys to be generated twice and the weak set to be used; the investigation is ongoing.
In May 2025, the Sectigo CA signed all eight intermediate certificates. Then, on October 17, 2026, an independent researcher notified the security teams at Mozilla, Google, and Apple, as well as the CA itself, that the keys were recoverable. On October 20, Mozilla publicly disclosed the incident. This means that for almost a year and a half the keys could have been recovered and certificates forged.
Using the vulnerable intermediate CAs, an attacker can sign a forged certificate for someone else’s domain. Clients that still trust that chain and have no other safeguards will take the forgery for the real server.
A certificate alone isn’t enough to intercept HTTPS traffic. The attacker also needs a way to tamper with the victim’s traffic or redirect the connection. That’s possible, for example, in a compromised office network, on a Wi-Fi access point the attacker controls, or by interfering with routing and DNS. And all of this does happen in the wild, as the DarkHotel attacks, among others, have shown.
There’s one more danger: two of the keys can be used for code signing. In theory, that would let an attacker deliver malware that appears to come from a trusted vendor and doesn’t trigger scary OS warnings during installation.
Was it exploited?
Experts from various companies who analyzed the after-effects of the incident haven’t found any malicious attacks that used these certificates. eMudhra and CERT-In have also reported finding no abuse. The Chrome team found no certificates from the six CAs in public Certificate Transparency logs.
This means that systems where browsers check certificates through Certificate Transparency (CT) were most likely not attacked. But many devices and applications — especially servers and IoT devices, don’t check CT at all, so we can’t say anything about them. Today, malicious actors no longer need to write their own hacking tools to pull off an attack like this. Version 12.3 of mitmproxy — a popular tool among security researchers — already has built-in support for compromised keys.
Where the risk has been eliminated, and where that isn’t guaranteed
Major platforms quickly revoked the compromised certificates. As early as October 17, Chrome did so through CRLSets, and Firefox — through OneCRL. On October 18, eMudhra itself revoked the certificates, citing “CA Compromise”. Apple took action on October 19, and the Sectigo CA also revoked the cross-signed copies. Microsoft revoked the certificates on October 20. Depending on the settings of a specific application and OS, revocation may have taken effect even without an application update, since blocklists are often updated separately.
At the same time, a more radical measure is under way: withdrawing trust from the root CA. Chrome has announced the planned removal of “emSign ECC Root CA – G3” from the browser. Certificates issued under the “emSign Root CA – G1” root, and the root itself, aren’t affected. According to eMudhra’s estimate, about 30 000 certificates will need to be migrated.
But certificate revocation only works where the client can find out about the revocation to then be able to actually act upon it. Many applications check the signature, server name, and certificate validity period, but don’t retrieve or update blocklists. Here are the typical cases:
Outdated and LTS systems. LTS (long-term support) status alone doesn’t mean a system is vulnerable. By definition, a system with this status receives support. But old containers, frozen OS images, and systems that are no longer updated can keep trusting revoked CAs for a long time. It all depends on updates to ca-certificates and TLS libraries, and the settings of the specific application.
Automated systems and servers. On emudhra.we-have-a-problem.com — a site created by enthusiasts where you can check any client software for misplaced trust — curl and Zabbix dominate the list of the most vulnerable systems. For HTTP checks, Zabbix usually uses libcurl and the certificate store configured for it. Similar behavior is also documented in the built-in curl in macOS. At the OS level and in Safari, the certificate is revoked, but curl reads a plain /etc/ssl/cert.pem file, and that’s precisely where the fix has to be made. This is a good example: even when system-level trust and revocation mechanisms work, individual applications — including ones that ship with the OS by default — can remain vulnerable.
Python, Ruby, Go, Java, and containers. An application may use its own set of root CAs, which isn’t updated along with the OS. Endor Labs found more than 25 popular packages that contain the affected root.
Slack, GitHub Desktop, and other apps built on the Electron framework. These apps ship with their own Electron/Chromium, so updating a separately installed Chrome doesn’t update Slack. The certificate revocations are already in the new Electron version, but now every developer has to rebuild and distribute their app, and every user has to install the update. That said, not every Electron app is necessarily vulnerable. The outcome depends on the version, how the app updates its blocklists, and which network stack it uses.
Mobile browsers and IoT devices. Mobile Chrome, Firefox, and Safari get certificate revocation data as quickly as their desktop counterparts do. With the stock browsers from smartphone makers, this isn’t the case. In a published test, Samsung Browser 31.0.0.64 accepted all six test chains from emSign while rejecting the ones from Sectigo. For HarmonyOS 6 and 7, researchers found the affected CAs in Huawei’s published list of root CAs, and those CAs can’t be revoked manually.
For unsupported devices, home appliances, and old firmware, a certificate store update may never be released. In those cases, the problem could linger for years.
Impact on TLS inspection in a corporate network
When an NGFW or web gateway inspects encrypted traffic, it maintains two connections: one with the client and the other with the external server. The client receives a certificate signed by the corporate CA, while the gateway itself verifies the authenticity of the external server.
If the gateway accepts a forged eMudhra certificate, even an updated browser on an employee’s computer won’t see the dangerous chain. Instead, it will receive the familiar corporate certificate. In this scenario, the security tool itself hides the problem from the client. That said, carrying out such an attack would also require intercepting traffic.
To fix the validation policy and certificate lists on the inspection device itself, follow the vendor’s instructions — if the vendor has published any, that is.
At Cisco, the status of the issue is documented in detail for all products. Most of them are still listed as “under investigation”, but mitigation measures are recommended for vulnerable devices.
Sophos and Check Point promise device software updates and, in the meantime, advise removing the certificates manually. Neither company has published a security advisory, but employees of each posted recommendations on its support forum.
For Fortinet devices, instructions for checking and removing emSign certificates can be found here. Palo Alto offered only general advice instead of specifics for its own products.
Of course, a properly configured gateway can indeed temporarily protect outdated client devices that trust the dangerous certificates.
To check specific devices, services, containers, and virtual machines, you can use a dedicated website. One possible scenario for proactively hunting for threats that exploit or have previously exploited weak keys is described here.
Contrary to a common misconception, people haven’t stopped enjoying books in the digital age. The truth is that for a while now, reading on paper hasn’t been the only way to enjoy the written word.
At first glance, what cybersecurity risks could there possibly be? But then, since there are more than a billion e-book readers in the world, cybercriminals are bound to try to cash in. We spoke with Andrey Sidenko, Head of Child Online Safety at Kaspersky, to learn how criminals exploit interest in e-books, and what to look out for so you don’t become a victim yourself.
Malware instead of a book
Most often, scammers target computer and smartphone users who try to download an e-book from a pirate site. For example, our experts recently discovered a miner spreading this way: it was tapping the processing power of infected computers to generate various cryptocurrency tokens. Several of these sites let visitors read e-book excerpts for free. In reality, the attackers were stealing passwords and using a malicious script to swap links: users got an archive with malware named the same as the book they wanted. What’s more, links to these sites sat at the top of search results, so the risk of taking the bait was very high.
A year ago, we also wrote about fake e-books in Turkish or Arabic. These files were actually malicious executables disguised as ordinary PDFs. Once launched, they installed infostealers on the victim’s device: malware that sent chat-app session tokens, browser files, saved passwords, and crypto wallet data to the cybercriminals.
Traps in search results
Sites that engage in search spam pose a danger of their own. Picture this: you search for “The Lord of the Rings free download” — and land on a page that repeats your search phrase word for word and supposedly offers that very book for download. But instead of the book you were hoping for, you may be redirected to yet another sketchy site and treated to a malicious file.
By the way, this scam can work even if you search for a made-up author and a made-up book. Such sites can automatically generate plausible download pages for just about any query.
Book phishing
There are also phishing scams aimed squarely at book lovers. For example, one group of scammers sent out fake emails to users pretending to be from the popular book community Goodreads, offering various bogus (paid) services, which, alas, some recipients fell for: becoming a moderator, taking part in book events, or buying a paid promotion.
Here’s another example: ads supposedly from Orell Füssli, a well-known Swiss bookstore chain, circulated on social media. The ads offered books at hefty discounts. To place an order, users had to follow a link and enter their bank card details. Our regular readers will have no doubt guessed that the link led to a fake site, which in this case simply set up a paid subscription billed to the victim’s card.
Finally, scammers often create phishing sites that pose as pirate libraries. These libraries no longer cater only to fiction readers: readers go there for textbooks, academic papers, studies, rare editions, and other material that’s hard to find publicly. Because such libraries get blocked regularly and have to keep changing domains, it can be hard for users to tell the real site from a fake one.
Attackers take advantage of precisely this by promoting their own sites as official mirrors. These fake sites are often fully functional: you can search for and download books just like on the real thing, and the design is almost indistinguishable from the original. In 2024, for example, data on almost 10 million users of a phishing site mimicking Z-Library, a platform providing free downloads of access-restricted books and publications, was leaked online.
The leak included names, email addresses, countries of residence, password hashes, purchase details, and even crypto wallet addresses. With data this detailed, it’s easy to plan a follow-up attack: say, posing as a police officer to accuse the person of visiting an illegal site and demand money to drop the criminal case.
Can an e-reader get infected?
For attackers, e-readers aren’t the juiciest target: it’s hard to predict what device someone uses, or whether that person even has internet access. Besides, most e-readers are basic models — essentially a flash drive with a screen.
But there are more advanced devices — with internet access, browsers, and the ability to download third-party apps and use cloud storage. These are more likely targets, but let’s be honest: most of the time, it’s cybersecurity researchers who hack them — not criminals. For example, in 2025, researchers discovered a vulnerability in the Kindle that could let an attacker hijack the linked Amazon account.
Data leaks and other less obvious risks
Some e-readers let you highlight quotes, take notes on books you like, and share either with other users. Attackers can use this data for doxing, especially if a person wants to keep quiet about reading a particular book — something like, say, Fifty Shades of Grey, or anything personal that isn’t meant for the public.
In 2020, a Guardian journalist requested a copy of her personal data from Amazon, and received more than 20 000 records regarding how she’d used her e-reader. These included which books she read and when, how long she spent reading them, which passages she highlighted or copied, and which words she looked up in the dictionary.
So it’s worth treating your reading history as personal data too. If a book service leaks data, or your account gets hacked, a bad actor could learn not just your email address but far more personal details.
So how do you read e-books safely?
One of the simplest tips is to use official bookstores — and not just for copyright reasons. Since these platforms value their reputation, their content is vetted — meaning the files are more trustworthy.
Another essential tip is to update all your devices regularly — even the most basic e-reader: if it runs an operating system and any software — keep those updated. Timely updates close vulnerabilities that attackers could exploit, which lowers the risk of being hacked. The same goes for apps for reading and cataloging e-books: this year, researchers found serious vulnerabilities in both Calibre and Koodo Reader.
Note that installing unofficial firmware on your devices — for example, closed-ecosystem e-readers like Kindle — may not be the best idea. Risks include bricking the device and losing your warranty. The device may die or lock up during flashing or later on — when an automatic over-the-air update installs official firmware. The manufacturer may also block your account if it detects the modified firmware when the device goes online. And, naturally, the firmware itself may carry malware, such as stealers that siphon off your personal data and passwords. The fact that there’s no way to install an antivirus on your e-reader only exaggerates the potential problem.
It’s also a good idea to back up your digital library from time to time. Buying a book doesn’t guarantee you’ll keep access to it in your account forever. A title may become unavailable because of changes to licensing terms, platform policies, or other restrictions. What’s more, some formats can only be bought and read inside the e-reader’s closed ecosystem. So we recommend keeping a backup copy on your computer or another device, where you can get to it quickly offline. That way, you’ll keep access to your content even if something goes wrong with either the book service or your device.
Every time you download an e-book, be sure to check the file extension. A regular e-book filename should certainly not end in .exe or .bat. You can read more about the most common extensions of malicious files here.
With scammers, alas, getting better and better at disguising malware, perhaps the best all-around advice is this: don’t visit dubious websites, and don’t download unknown files. This is where Kaspersky Premium comes in: one of its main features is protection against phishing and malware. The application warns you if you try to visit an untrustworthy site, or download a potentially dangerous file. This keeps your data and money safe, and you can download and read your favorite books with peace of mind.
Love the written word? Check out our other posts about books:
AI systems are much harder to protect than traditional IT — whether from operator mistakes, malicious interference, or just plain unstable behavior. There are two main reasons for this. First, AI outputs are probabilistic, so the same prompt can give different answers each time you run it. Second, today’s LLMs can’t reliably tell commands apart from data. Despite the demonstrated security issues of AI systems that we’ve covered many times, it’s impossible to ignore the potential economic payoff of adopting them. That’s why many companies are moving beyond simple AI assistants to AI agents. These agents carry out tasks on their own and have direct access to the same tools as humans — from reading databases to changing settings in production processes. Our experts, in their new study, examine how to clearly define and minimize the resulting risks to keep potential problems to a minimum. The approach borrows and adapts the principles of Cyber Immunity and Security by Design.
The basic principles of Security by Design
All the principles of this discipline are universally applicable to the design of any computer system — AI agents included. What differs is how deeply each principle needs to be adapted and reworked for AI scenarios.
Security is a separate and important factor right from the design stage. Security goals and assumptions are set on day one and followed throughout every stage of development. For AI agents, these assumptions should include three key points: (i) the language model is treated as untrusted, (ii) external data of any kind is considered potentially malicious, and (iii) irreversible actions can’t be performed autonomously without mandatory human approval.
The system is designed on the assumption that it will be attacked.
The trusted computing base and attack surface are kept to a minimum. Agents get only the tools they actually need, limited permissions, and the smallest amount of context possible. Security policy enforcement is handled entirely by deterministic components: the policy monitor, the agent harness, and isolation mechanisms (sandboxes).
The principle of least privilege applies. Each agent has its own set of credentials and access privileges (identity), limited to the bare minimum it needs to do its job. If an agent temporarily needs elevated privileges, it gets them only after external approval, and they last exactly as long as the task that requires them.
Components are isolated. In agent-based systems, this is one of the most complex and multi-layered architecture problems. The agent harness should run in an isolated environment (sandbox or virtual machine), and agents should be kept as isolated from each other as possible. Data processing in trusted and untrusted contexts is also kept separate. For example, one agent reads a pull request and writes a draft of the code, while another reviews that work without ever seeing the potentially malicious text of the request.
Default deny is the rule. Security policies follow the rule: anything not explicitly allowed is forbidden. This includes tool calls, interactions between agents, and network traffic.
Defense in depth is in place. Different measures should work at the same time and reinforce each other. Probabilistic defenses — like AI guardrails (a “firewall” for language models) or alignment (the model’s own sense of what’s acceptable and what isn’t) — can’t offer any formal security guarantees. Nevertheless, they make the system more secure overall and serve as a valuable source of telemetry.
The supply chain is protected. Some agents can install skills, libraries, and other software components on their own, so these abilities need strict rules. Either block them completely, or limit them to a closed, pre-approved list of specific versions of specific components. Systems built on cloud LLMs face an extra risk: model updates. One day, the same API request might be answered by a different language model with different security properties.
Pitfalls of AI security
The general principles of Security by Design are well known and look simple on paper. But applying them to AI systems is tricky because agents are incredibly flexible. For example, a security team might believe that an agent on a developer’s computer runs in a sandbox and can’t change anything outside it. But an attacker, or even the agent itself, can come up with dozens of ways around this seemingly solid protection: from running commands through a local MCP server that the sandbox doesn’t restrict, to reconfiguring another AI agent installed on the system. To make things even harder, the range of attack vectors is huge: from arbitrary fields in the agent’s configuration to innocent-looking text strings in a skill file.
One serious problem that designers often underestimate is user fatigue. A busy agent can throw up dozens of requests every minute, asking the user to confirm potentially dangerous actions. Within an hour, the person is clicking Approve on autopilot without reading what they’re approving. That’s why it’s important to carefully tune both how often these requests appear and how they’re worded. Nobody will read a request description that’s too long. And one that’s too short can hide the key details the user needs in order to make the right call.
Vulnerabilities in agents and related tools are a pressing problem — and it’s made worse by how quickly these categories of software evolve and receive updates. Industry-standard platforms and apps — such as LangGraph, MS Semantic Kernel, and Claude Code — have had critical vulnerabilities patched more than once. Architects should always consider swapping a large, do-it-all framework for a compact, stripped-down system that has only the features a specific agent actually needs.
On top of that, carefully implementing standard, long-established security measures in the available tools greatly reduces the damage if an agent is attacked or behaves unexpectedly. One example is a strict allowlist of domains that the web fetch tool can open when asked by the agent. But designers rarely account for the hidden problems and overhead associated with maintaining the list. As a result, it slowly goes out of date and leaves loopholes for attackers. The most striking example is the EchoLeak attack. Microsoft 365 Copilot had a properly implemented and fairly effective allowlist for accessing external sites, but attackers circumvented it through a feature in a secondary tool and the MS Teams domain.
Practical tips for architects and security teams
AI system architects and heads of engineering and security teams should build in agent security from the design stage. They should rely primarily on verifiable, deterministic mechanisms: isolating components, controlling interactions, and keeping the trusted computing base to a minimum.
Key architectural decisions include defining acceptable autonomy for the agents, limiting access to confidential data and dangerous combinations of capabilities, and using sandboxes, separate roles for different models, and access control gateways. Restrictions added as an afterthought reduce risks, but they’re no substitute for secure architecture.
At the organizational and operational levels, companies need to keep an inventory of their agents, coordinate the efforts of security and deployment teams, protect container environments, manage the supply chain (AIBOM), and integrate multi-layered defense.
Observability requires special attention. For AI systems, this should include logging the LLM’s requests, responses, and reasoning, as well as detailed telemetry from the hosts and cloud environments where the agent harness runs.
The hardest part of designing agents is balancing security, performance, and usefulness. To learn how to strike that balance with threat modeling and clearly defined security goals, read the full version of the study.
You might not expect a disaster recovery company to weigh in on business email compromise (BEC). But the fact that we are the ones talking about it is a sign that, too often, something’s gone wrong.
When we give our private information to the government to pay taxes, apply for a job, or vote, we should be able to trust that our data won't later be used against us. But in a betrayal of that trust, the federal government has been pooling the information it has about us on an unprecedented scale—and using it for purposes we never agreed to.
For over 35 years, EFFector has been your guide to understanding the intersection of technology, civil liberties, and the law. This issue covers our free tracker blocker coming to Safari, a call to action for net neutrality in California, and a big win in our lawsuit against the DOGE data grab.
Prefer to listen in? EFFector is now available on all major podcast platforms. This time we're talking to EFF's F. Mario Trujillo about the dangers of government data grabs—and what defenders of privacy are doing to stop it. You can find the episode and subscribeon your podcast platform of choice:
Want to protect your right to digital privacy? Sign up for EFF's EFFector newsletter for updates, ways to take action, and new merch drops. You can also fuel the fight for privacy and free speech online when you support EFF today!
HomeWizard introduceert de Temperature Humidity Meter voor het meten van de temperatuur en luchtvochtigheid. Het apparaatje werkt op een oplaadbare accu en vereist geen hub of bridge. De Temperature Humidity Meter is vanaf 27,95 euro verkrijgbaar en wordt vanaf 30 november geleverd.
De Nederlandse politie heeft in een internationaal onderzoek naar een hostingbedrijf tientallen servers in beslag genomen bij een datacentrum in Limburg. Het bedrijf zou betrokken zijn bij uiteenlopende vormen van cybercrime, van ransomware en infostealers tot phishing en kindermisbruikmateriaal.
OpenAI is van plan om tensor processing units van Google te kopen. Dat melden Bloomberg en The Information op basis van ingewijden. Het bedrijf zou zo minder afhankelijk worden van Nvidia, wiens chips OpenAI nu voornamelijk gebruikt voor het trainen en draaien van zijn AI-modellen.
Microsoft again asked Entra ID administrators to migrate users to phishing-resistant methods to avoid sign-in disruptions before it retires SMS and voice authentication in February 2027. [...]
Attackers are actively exploiting vulnerabilities across critical network infrastructure, and PHP flaws known as "PHP2Shell" put the web management interfaces of firewalls, VPNs, application delivery controllers, and other appliances at risk. [...]
The massive funding round comes just days after reports emerged that Upwind had attracted acquisition interest from several companies, including Datadog
PHP2Shell shows how quickly attackers can exploit critical vulnerabilities, often before organizations have time to patch. Token Security explains why limiting the access of service accounts, API keys, and AI agents is just as important as fixing vulnerabilities to reduce the damage from a breach. [...]
Login
