I wanted to share a great free resource for anyone trying to bridge the gap between basic theory and actual hands-on security skills.

The Czech Technical University in Prague (specifically the Stratosphere Laboratory) runs an intensive, one-semester course called Introduction to Security (BSY) that starts this week. The class is being taught both physically at the university and broadcast online, so anyone can participate. Feel free to check the link for more details on the curriculum, prerequisites, and course structure.

Registration is still open!

Last year I inherited a “critical RCE” from an automated pass.

The request looked perfect. Parameter host. Payload 8.8.8.8; sleep 5. Status 200. Response time jumped from ~800ms to ~6s. The scanner wrote OS command injection, confidence high. The client had already seen the word critical in the draft.

I replayed it once. Same delay. Replay again. 1.1s. Again. 7s. Again. 900ms. The sleep was not in the response body. id came back as the literal string id. expr 41 + 1 came back as the literal string. The page was a diagnostics form. It echoed the query and, under load, the WAF in front of it spent extra time on anything that looked like a shell metacharacter.

That is a known failure mode, not a rare one. Time-based command-injection checks fire when the response is merely slower, which also happens when the scan itself saturates the app, when a WAF inspects a “more suspicious” request, when a CDN queues you, or when the page is just doing a heavier search. SANS has been writing this up for years: ping -c 20 127.0.0.1 during a busy scan is not proof. ZAP’s sleep payloads have the same problem, and in some rules even reflecting the command string is enough to raise the issue. A 200 that contains bash -c is often a docs page, not a shell. 

The useful question is not “did a payload land.” It is “what value in this response can only exist if the server evaluated my input?”
What I do now, on the same request, before I write the word confirmed:

1. Send a benign twin. Same cookies, same content-type, same parameter, no metacharacters. That is the control. If the “interesting” string is already there, stop. That is echo, not execution.

2. Do not ask the server to say whoami. Ask it to compute something it has never seen. Two random integers, added, wrapped in canaries that are also random for that probe. If the body contains the sum and the control does not, you have a result that reflection cannot invent.

3. If there is no output channel, do not promote a single slow request. Change the delay. Plot it. If 3 / 7 / 11 seconds do not track the payload, it is jitter or a WAF. PortSwigger has a nice version of this trap: an exec-looking parameter delayed because the WAF worked harder, not because a binary ran. 

4. A DNS callback is a sink, not a shell. Collaborator lighting up after you plant a URL is often a link previewer, a safe-browsing fetch, or a JNDI lookup that never loaded a class. Fastjson / Log4j writeups on here keep dying at that step: four DNS hits, zero command. Say lookup. Do not say RCE until a value only the target could have computed comes back, or you have a class-load you can show.

5. If your flags never built a probe for that sink, the result is not negative. It is untested. I have watched people paste “not vulnerable” into a report because the scanner used shell separators against an OGNL parameter. Struts will happily evaluate %{7*7} and still return nothing useful to ; id. Wrong claim, clean-looking ticket.

The ticket I inherited was closed as a false positive in fifteen minutes once the control existed. The next one, on a lab Webmin box, survived because the response contained a sum the request never sent. Same scanner family. Different question.

If you only remember one thing from this: before you file P1, ask whether a second person can reproduce a value, not a delay. Triage queues are full of the second kind. That is why “not reproducible” shows up on reports that felt obvious at 1 a.m.

I later wrapped the control + random-arithmetic check into a small stdlib-only helper so I would stop doing it by hand on jump boxes. That is not the point of the post. The point is the question. If you want the benches against Webmin / Struts2 / a Log4j lookup so you can disagree with the verdict names, I will drop the repo in a comment.

CVE-2026-59309 & CVE-2026-59310: patch-diffing VMware vCenter reveals two pre-auth 9.8 bugs - an auth bypass and a syslog path traversal to RCE

Technical write-up for four vulnerabilities I reported in ZTE SmartLife.

The main issue is CVE-2026-86553, a password reset flaw in the SmartLife account backend. The reset endpoint accepted the target accountId and a new password without requiring a reset code, old password, or validated reset transaction.

Another endpoint exposed whether an email was registered and returned the corresponding backend account ID. Using researcher-controlled accounts, the chain was:

email -> accountId -> password reset -> login with the new password

I verified the state change by confirming that the previous password stopped working and the newly selected password successfully returned a valid session.

The research also covered the app authentication mechanism used by the Android client, email ownership verification during registration, and the wider SmartLife/Homecare SDK surface available after login.

ZTE patched the reported issues and assigned CVE-2026-86552, CVE-2026-86553, CVE-2026-86554 and CVE-2026-86555.

Author here. The post describes three memory-safety bugs which have been in Godot since v1.0 and v3.0. All three are still present in current releases. The bugs can affect exported games that load community-authored data files. Godot allows attackers using maliciously crafted files to trigger reads or writes past the end of a buffer, inside the process running the game. The post includes the response from Godot maintainers who deny this is a security issue, and my reply to them. Happy to give more information about the bugs or the audit if there are questions.

I have been developing a tool wrapped around tshark. The first blog post was about hitting a wall on a 2.5 GB file. Later, I talked about parallelizing the PCAP processing in my second blog post where I ran into a file corruption bug. I was using PcapSplitter from PcapPlusPlus in connection mode and output started coming back corrupted.

The initial signal came from "Total Block Length" errors thrown by tshark on some output files. The actual signal came when I built a small reproduction. PcapSplitter reported 12 files and 48 packets, but on disk, there were 11 files and 44 packets. Exit code zero and printed "Finished" on standard output.

Two wrong theories first. Someone on Reddit suggested file descriptor exhaustion. It was plausible but I found that at low ulimit -n it silently drops most packets and still exits zero. A real bug, but not mine. Then, I found that the PcapSplitter library has a hardcoded MAX_NUMBER_OF_CONCURRENT_OPEN_FILES = 250 with an LRU that closes and reopens handles past it. My minimal reproduction was 13 connections, nowhere near the cap.

The real culprit: the PcapSplitter's FiveTupleSplitter caused file truncation/corruption on TCP session reuse (i.e., a new SYN packet arrives for an already tracked 5-tuple hash).

The correct part of the splitter was assigning a new file number when a TCP session reuses a 5-tuple, but the filename function builds the name from IP and port only. So, in this case, both sessions get the same filenames. Then main.cpp sees a file number it has never seen, and opens that file fresh, without append. This truncates the existing file or causes a race condition between two active file writer handlers.

I filed the issue with a 13-connection reproduction, the maintainer and I worked out a fix that only suffixes on an actual collision, tested on the same corruption, and now the fix is merged.

Hi folks, my name is Gal Weizman, I do browser security research.

Excited to finally share my recent work, where I managed to hack Chrome, Comet, Edge, Opera and Claude in Chrome using one single browser extension

2 CVEs & $20,000 in bounties 🙂

Hope you like it!

Attackers are opening Microsoft Teams chats from tenants they control, using a display name like IT Service Desk, and talking people into either installing a file or handing over a remote session. Teams allows chat from any external domain by default, and the attacker only needs the target to say yes once. In the case Expel documented, the yes was an MSI hosted on a Microsoft Azure storage endpoint; the payoff was a fake Windows lock screen that captured the user’s password in the clear. Two settings in the Teams admin center and one sentence said out loud to your staff close most of this.