Evidence, Or It Doesn't Count

Levinitycyber

Evidence, Or It Doesn't Count is a security show for the age of AI, hosted by Moshe Levy, founder of LevinityCyber. Everyone claims their tool is smart and their defense is airtight. This show only cares about the receipt: real vulnerabilities found in real software, reported responsibly, and fixed and credited by real vendors. Short episodes, plain language, public proof. Built by the founder of an autonomous AI engine that hunts vulnerabilities around the clock.

Episodes

  1. 5d ago

    The One We Vouched For

    For three episodes now the same company keeps showing up on this show, and that is a compliment. IBM builds in the open, takes the report, ships the fix, and puts our name on the advisory. This is the third time, and this one earned a score I almost never say out loud: a perfect ten out of ten. No login, no warning, a stranger running code on the host. The highest number the scale can give. Here is what makes it the right story for where this show has been heading. The agent did not escape by finding a hole someone forgot to close. It walked out through a door we held open for it. These agents write and run their own code inside a sandbox, with a blocklist of dangerous tools and an allowlist of safe ones. The blocklist worked perfectly. The thing that got out was on the safe list: an ordinary, boring data tool with one quiet feature that could reach the internet, pull back a file, and run whatever was hidden inside it. The gate was told to trust the tool. Nobody checked what the tool could do once trusted. That is the whole theme of the episode: trust runs in both directions. First from us into the machine, because a human wrote that safe list and the machine obeyed it faithfully, right off a cliff. And then from the machine back to us, because after a month of good days you stop reading the output and you click approve at five to five on a Friday. Nobody reads closely after a month of being right. A ten out of ten lives in exactly that gap, between the last time anybody looked and the first time it mattered. We ground it, as always, in a public and credited finding: a Critical sandbox-escape remote code execution in IBM Research's open-source CUGA agent, reported by us, fixed by them, and published with our name on it. We close with the four defenses that actually help: allowlist the specific jobs a tool may do, not the whole tool forever; treat every trusted tool as a way in, not a thing at rest; keep a human in the loop who is still genuinely reading, and rotate them; and when a bug is found, do what IBM did, close the door in public and credit the people who told you. Chapters 00:00 Cold open 1:57 A perfect ten, and the receipt 3:43 The door we held open 5:53 Told to trust: us into the machine 7:29 A month of being right: the machine back to us 9:38 The fixes 11:34 Three for three, and what's next Links Research and disclosures: https://levinitycyber.com/research This episode, IBM CUGA agent sandbox-escape RCE: https://levinitycyber.com/research/ibm-cuga-agent-sandbox-escape-rce Advisory: GHSA-2xq5-x376-qqh2, CVSS 10.0 Critical, cuga-agent fixed in 0.4.3, published 2026-10-25. Credited: Moshe Levi, LevinityCyber. Vendor: IBM Research. Episode nine callback, IBM CUGA cross-principal memory: GHSA-ffh4-qv86-xfxv, fixed cuga-agent 0.4.1 Episode one callback, IBM CUGA file read: GHSA-q5xm-fr98-g4j5 Evidence, or it doesn't count. Real bugs. Real vendors. Public receipts. Hosted by Moshe Levi, LevinityCyber.

  2. Oct 21

    The Robots Started Trusting Each Other

    Ten episodes ago we made one promise: every bug on this show would be real, reported, fixed, and public, with our name on the advisory. Ten in, that bet holds. So for the milestone, we look back to go forward. There is a pattern running underneath almost every episode, and it is not a pile of unrelated bugs. It is one bad habit, failing in a new place each time. An agent trusted an input it should have questioned. Then an agent trusted a tool on someone else's machine. Then an agent trusted its own memory, including a note a stranger slipped in. Each time, the thing it over-trusted moved one layer further out from the machine itself. This episode follows that line to where it is heading: teams of agents that trust each other. What everyone is building now is not one agent, it is a planner, a researcher, a writer, a critic and a runner passing work back and forth and reading each other's notes. That is fast precisely because nobody re-checks the teammate's work. So a single bad fact, picked up anywhere in the chain, gets written down as a finding, believed by the next agent, built upon, and cited again, until it has a convincing fake provenance and the whole swarm is confidently wrong together, with a paper trail that makes it look carefully checked. We cover why a swarm is worse than one brain (you lose containment, attribution and doubt at once) and the four defenses that actually help: treat an agent-to-agent message as untrusted input, keep provenance attached to every fact, put a real skeptic in the loop, and never wire swarm output into anything irreversible without a human who is still genuinely reading. And we close on a fresh receipt: a critical, unauthenticated flaw we just reported in a widely used WordPress privacy plugin, public and credited, with the details held back until the vendor ships the fix. Chapters 0:00 Cold open 1:51 Nine receipts, one pattern 3:56 Now there are many 6:18 How a lie travels 8:44 Why this is worse than one brain 11:00 The part people get wrong, and the fixes 13:49 Ten episodes, and what's next Links Research and disclosures: https://levinitycyber.com/research IBM CUGA cross-principal knowledge access (episode nine): GHSA-ffh4-qv86-xfxv, fixed cuga-agent 0.4.1, LevinityCyber credited IBM CUGA file read (episode one): GHSA-q5xm-fr98-g4j5 Borrowed-tool over-reach (episode three): CVE-2026-75612 This month's finding, GDPR Framework by Data443, unauthenticated PHP Object Injection, CVSS 9.8, credited LevinityCyber: CVE-2026-39797 Evidence, or it doesn't count. Real bugs. Real vendors. Public receipts. Hosted by Moshe Levi, LevinityCyber.

  3. Oct 14

    The Memory That Belonged to Someone Else

    Last week the AI obeyed a hidden instruction once, and then the task ended. This week, it does not forget. This episode is about memory poisoning: when an AI assistant has a long-term memory, a single sentence planted once can be filed away as something it simply "knows," then quietly carried into every conversation after. The stranger does not have to stay in the room. They leave a note in the pile the assistant trusts, and a completely different person gets the answer that note shaped. We ground it in a brand-new, public, credited finding of ours: a cross-principal knowledge-access flaw in a research agent built by IBM. Our engine found that one principal could read, change, and even delete another principal's knowledge, because the system confused authentication ("is this our own component?") with authorization ("whose data is it allowed to touch?"). It is the sequel to the very first finding we showed on this show, back in episode one. Reported, fixed in version 0.4.1, and public. We cover why a shared agent memory is the softest target in the system, why cross-principal access plus persistence equals a durable implant where the attacker and the victim never meet, and the three defenses that actually help: treat a memory write as a privileged action, never ship isolation as a demo-only toggle, and let people see, correct, and wipe what the machine remembers about them. Chapters 00:00 Cold open 1:46 The lie that gets filed 3:35 One brain, many clients 5:37 The receipt: IBM, again 8:26 Where the two episodes click 10:41 The part people get wrong, and the fixes 13:03 Next week, and close Links Research and disclosures: https://levinitycyber.com/research IBM CUGA cross-principal knowledge access: https://levinitycyber.com/research/ibm-cuga-agent-cross-principal-knowledge-access.html Advisory: GHSA-ffh4-qv86-xfxv (github.com/advisories) — fixed cuga-agent 0.4.1, LevinityCyber credited Episode one callback, IBM CUGA file read: GHSA-q5xm-fr98-g4j5 Evidence, or it doesn't count. Real bugs. Real vendors. Public receipts. Hosted by Moshe Levi, LevinityCyber.

  4. Oct 8

    Who Told the Robot It Could Do That

    Your AI assistant does exactly what it is told. That is the problem. This week on Evidence, we get into indirect prompt injection: how an obedient AI helper can be talked into handing your secrets to a stranger, because somewhere in the content it was asked to read there was a second instruction. One you never wrote. One you never saw. No break-in, no stolen password. Just a sentence, hiding in plain sight, written in the one language the machine was built to obey. We get into why every AI task now has two authors, where the hidden instruction lives (a web page, a PDF, a support ticket, a calendar invite), why "just ask the model to ignore bad instructions" does not work, and the three defenses that actually help: treat everything it reads as untrusted, take away what it does not need, and keep a human hand on anything that matters. Grounded in public, credited receipts from our own work: our file-read finding in a research agent built by IBM (episode one), and our finding in a media tool that over-reached, CVE-2026-75612 (episode three). Chapters 00:00 Cold open1:42 The second author3:26 A sentence that hides in plain sight5:54 The receipts: IBM and the media tool7:52 The fixes that actually help10:24 The part people get wrong12:08 Next week, and close LinksResearch and disclosures: https://levinitycyber.com/researchyt-mcp advisory: CVE-2026-75612 (cve.org)IBM CUGA advisory: GHSA-q5xm-fr98-g4j5 (github.com/advisories) Evidence, or it doesn't count. Real bugs. Real vendors. Public receipts. Hosted by Moshe Levi, LevinityCyber.

  5. Sep 30

    The Tool on Someone Else's Computer

    Your AI assistant can't actually do anything on its own. It can only talk. So to book the flight, read the file, or check the page, it borrows tools, and a lot of those tools don't live on your device at all. They run on someone else's computer, each one holding its own keys to the service behind it. That's fine, until you ask a borrowed tool to fetch one small file and it fetches the wrong one. This week: a tool whose only job was to read a file, pointed instead at the server's own private key, handing an outsider the credentials to the whole account it belonged to. Ask for a document, get back the deed to the building. We've stood here before with our own name on it: an MCP media-server tool we reported could be nudged out of its lane, on the public record as CVE-2026-75612, credited to LevinityCyber, and fixed. The through-line isn't one careless developer. It's the seams between tools, the handoffs where one program trusts another and nobody's watching the door. We're not adding features to our assistants anymore, we're adding relationships, and a wall is no help once the thing you should worry about is already inside, wearing a badge somebody printed for it. What to do tonight: find out what tools your AI assistant is actually connected to, and what each one is allowed to touch. Turn off the ones you forgot you connected. If you build with these tools, give every one the least power that does its job and not a drop more, put the limit in the code, and treat every key a tool carries like the password it is. Evidence, or it doesn't count. Links Our media-server finding — CVE-2026-75612: cve.org/CVERecord?id=CVE-2026-75612 Our disclosure wall: levinitycyber.com/research Levinity Cyber: levinitycyber.com Chapters (add these lines into the description — Spotify builds chapters from them): (0:00) Cold open — the keys that were never yours (2:21) What your assistant actually borrows (4:04) Our receipt: the media server (5:44) The tool that read the whole disk (7:21) What a leaked tool key is really worth (9:03) Why this keeps happening (10:36) What to do tonight (12:01) Where I land + what's next

  6. Sep 23

    The Chatbot That Gave Away

    The friendly little AI chatbot in the corner of a website has a job, and to do it, it keeps two things: a key to the AI service behind it, and the business's real contact channels. On a lot of sites, both were sitting in a drawer anyone on the internet could open. No login. No trick. Just knowing which drawer to pull. This week, two findings from one company, QuantumCloud. In SiteLeads, a lead-and-chat widget, all the settings — the AI key, the phone, the email, the Telegram — were quietly published to the open web, readable by anyone. Reported through Patchstack, fixed in the next release, and on the public record as CVE-2026-78268, credited to LevinityCyber. In their other chatbot plugin, WoowBot, the opposite door was open: a missing check let any logged-in user change the plugin's settings. We get into what a leaked AI key is actually worth, and the one idea underneath it all: storing something and locking something are two different jobs, and the second one keeps getting skipped. QuantumCloud handled both the right way — fixed fast, and cleared us to tell the story. Chapters (0:00) Cold open — the front desk with the unlocked drawer (2:00) Every AI helper holds two secrets (4:17) The SiteLeads leak — one address, no login (6:14) WoowBot — same vendor, the opposite door (8:34) What it's actually worth to an attacker (12:05) Why this keeps happening — AI keys are the new passwords (15:24) What to do tonight (check your own site) (18:28) Outro What to do tonight: if there's an AI helper on your site, find out what it is and update it. If you build software, never store a secret anywhere that can be published, and put the lock in the code, not in the label. And treat every AI key like the password it is. Evidence, or it doesn't count. Links CVE-2026-78268: cve.org/CVERecord?id=CVE-2026-78268 SiteLeads writeup: levinitycyber.com/research/siteleads-unauthenticated-sensitive-data-exposure WoowBot writeup: levinitycyber.com/research/woowbot-woocommerce-missing-authorization Disclosure wall: levinitycyber.com/research Levinity Cyber: levinitycyber.com #CyberSecurity #InfoSec #AppSec #AISecurity #WordPress #WordPressSecurity #APISecurity #AIChatbot #DataLeak #ResponsibleDisclosure #CVE #BugBounty #SecurityPodcast #LevinityCyber

  7. Sep 16

    The Wall Between Us

    Almost every business tool you use now lives in a shared building. One piece of software, one set of servers, thousands of separate companies inside, each on its own floor, walled off from the rest. That wall is not a feature. That wall is the whole product. So what happens when the wall was drawn on, and not built? This week, a real one. We found a cross-company hole in Horilla, an open-source CRM, where any ordinary logged-in employee at one company could change a single number in the web address and land inside another company's sales pipeline. Reading it. In places, rewriting it. No password, no exploit, nothing you would see in a movie. The software checked that you were allowed to touch pipeline data. It never checked whose. Then the part that actually matters. The maintainer shipped a fast fix, we checked the lock ourselves, and four doors were still open. We said so, they closed those too, and we verified it. Published as a GitHub Security Advisory (High, 7.6), credited to LevinityCyber. And it is the same shape we keep finding, from an AI agent at IBM down to a tiny open-source project: software that trusts the request, instead of the requester. Chapters: (0:00) Cold open, the office tower nobody checks (2:02) What "multi-tenant" really means, and why you can't see the wall (3:45) The finding, change one number, walk onto another company's floor (5:56) The fix that wasn't, and the pattern behind it (7:43) What to do about it What to do tonight: if your company rents its software, ask your vendor one plain question, how do you stop another customer's users from reaching my data? If you build multi-tenant software, never let the visitor decide whose data they see. And when someone hands you a fix, open the door and check the lock yourself. Evidence, or it doesn't count. Links: Horilla advisory (GHSA-m85w-6gg6-mvwm) Full technical writeup Our disclosure wall Levinity Cyber

  8. Sep 10

    The Doors That Never Locked

    Roughly forty percent of the web runs on one piece of software: WordPress. The core is mature and battle tested. The real risk lives one floor up, in the plugins. The booking calendar, the review widget, the chatbot in the corner. Every one of them is code written by someone you have never met, handed a set of keys to your entire site. This week: what happens when you point a tireless machine at that entire surface and let it run for months, and then show the receipts. The whole episode is about one unglamorous class of flaw, missing authorization: a door that is supposed to be locked and simply is not. It is the family at the top of the OWASP Top Ten, number one since 2021, and it is behind more real breaches than any exotic exploit. The receipts, all public and all patched before we said a word: An SEO plugin where a low-privilege user could reach the site's Google indexing controls. Reported, confirmed, patched, and published as CVE-2026-15252, credited to LevinityCyber. A multi-vendor marketplace plugin where one seller's actions reached straight into another vendor's dashboard. A survey plugin whose first official patch did not actually close the hole, the story we told in Episode 2 (CVE-2026-65565). A learning-management plugin leaking active exam answer keys to anyone. And three more of the same archetype from vendors who handled disclosure like professionals: they answered, they fixed it, and they gave us written permission to tell the story. Having a bug is not the scandal. How you react the minute a researcher flags one, that is the character test. What to do tonight: delete every plugin you are not actively using (deactivated code still runs). Check the last-updated date on the ones you keep. Give every account the least power it needs, and not one click more. Evidence, or it doesn't count. Links: - CVE-2026-15252: https://www.cve.org/CVERecord?id=CVE-2026-15252 - CVE-2026-65565 (Episode 2): https://www.cve.org/CVERecord?id=CVE-2026-65565 - Full disclosure wall: https://levinitycyber.com/research/ - Levinity Cyber: https://levinitycyber.com Find me on LinkedIn and X, or email info@levinitycyber.com. #WordPress #security #pluginsecurity #missingauthorization, #brokenaccesscontrol #OWASPTopTen #responsibledisclosure #bug bounty #CVE #applicationsecurity #AppSec #supplychainsecurity #websecurity

  9. Sep 3

    The Machines We Let Off the Leash

    Enterprise tech just invented a new kind of worker, the AI agent, and handed it our files, our credentials, and our production databases before teaching it to say no. This episode follows that one missing lesson through three real incidents. First, a finding from our own lab: an open-source MCP server whose "attach a file" tool would read any file on the host, secrets included, and hand it back in plaintext. We reported it, the maintainer patched it, and it is now public as CVE-2026-75612, credited to Levinity Cyber. Then the honest footnote, a real authorization bypass we found in Google's Gemini CLI tooling and lost to a duplicate ticket, no credit, kept in the episode anyway. From there we leave the lab: the dealership chatbot talked into selling a Chevy Tahoe for one dollar, and the airline that told a tribunal its chatbot was a "separate legal entity." Same root cause every time, agency plus untrusted input plus zero refusal logic. The fix is not a smarter model. It is the oldest principle we have, least privilege. Evidence, or it doesn't count. https://github.com/velesnitski/yt-mcp/security/advisories/GHSA-99mq-fjjc-6v9j · CVE - https://www.cve.org/CVERecord?id=CVE-2026-75612 - The $1 Chevy Tahoe bot: https://incidentdatabase.ai/cite/622/ (canonical incident record) · news write-up: https://cybernews.com/ai-news/chevrolet-dealership-chatbot-hack/ - Air Canada chatbot ruling (Moffatt v. Air Canada, 2024 BCCRT 149): https://www.canlii.org/en/bc/bccrt/doc/2024/2024bccrt149/2024bccrt149.html (the actual tribunal decision) https://levinitycyber.com/research/ · https://levinitycyber.com

About

Evidence, Or It Doesn't Count is a security show for the age of AI, hosted by Moshe Levy, founder of LevinityCyber. Everyone claims their tool is smart and their defense is airtight. This show only cares about the receipt: real vulnerabilities found in real software, reported responsibly, and fixed and credited by real vendors. Short episodes, plain language, public proof. Built by the founder of an autonomous AI engine that hunts vulnerabilities around the clock.