OSWE review

I passed OSWE on 22 October 2025, first attempt, with both targets fully done. Everyone tells you OSEP is the hard one. For me OSWE was harder, and it wasn’t close. It’s unpredictable in a way OSEP isn’t: you’re staring at a pile of source code and it’s very easy to get lost and overwhelmed. But the stuff you come away with is gold, and it felt worth it by the end.

Where I was coming from

Honestly, I went in with almost no web app development knowledge. I’d done the fundamentals back in university, but by the time I was looking at the modules it was chaos. I had BSCP, which helped a little. So if you’re not a developer, know that you can still get through this, but expect the code side to hurt early on.

How I studied

I took the 90-day lab access and spent close to three months just going through the material. The challenge labs were the most useful part, because they let me prepare a lot of my Python scripts ahead of the exam. On the exam I mostly just had to adjust how the requests were being handled.

I went with Python for the exploit scripts. Not because it was the easiest, but because everyone I spoke to said to stick with it, and there are a lot of ready-made Python scripts out there for these scenarios. Two repos that helped me a lot:

• rizemon/exploit-writing-for-oswe, which covers the Python side: spinning up a Flask server, sending data in the URL, blind SQL injection, and more. A lot of my exam scripts started here.
• computer-engineer/WhiteboxPentest, a good rundown of the kinds of vulnerabilities to expect based on the syllabus.

I also leaned on Claude a fair bit to break down concepts I didn’t understand and to help me put the Python scripts together.

The regex that carried me

This was the most important part of my prep, so I’ll spend a minute on it. It’s close to impossible to spot the vulnerabilities just by reading the code, at least it was for me. What made the difference was building a set of regex patterns to hunt for the vulnerable code: dangerous sinks, user-input entry points, the usual suspects.

I built the list as I went through the material and the challenge labs. It ended up large, and a lot of it turned out to be redundant, so I redid it several times. I ordered it so the common, easy-to-grep bug classes surfaced first, and left the subtle, multi-step stuff for after. Get the obvious patterns working before you go hunting for the clever ones.

One thing that tripped me up: the regex finds more than one vulnerability, and it’s easy to convince yourself that whatever it just found is the one you’re looking for. It might not be. It could belong to a later stage of the chain. So note what you find, but don’t assume the first hit is the piece you need right now.

The exam

I got the first target on day one, roughly 14 hours in. It was exhausting. The whole thing took me about 30+ hours, and I left the rest for the report. I got maybe 3-4 hours of sleep each day.

Finding the vulnerabilities was the slow part, especially the initial access. What I learned the hard way is that reading the source top to bottom is a trap. I tried it at first and it was like reading a book without taking in any of it, probably because of my weak web dev background. So I stopped doing that and tracked the application flow instead: what loads at the point I was attacking, what redirects where, what gets loaded next.

Here’s the thing I wish someone had told me beforehand. Look at the code that’s relevant to what you’re trying to do. If you’re after an auth bypass, read the authentication code and anything linked to it. If you’re after privilege escalation, read the code around that. Don’t try to understand the whole application. Understand the part you’re attacking.

I got properly stuck for the first six hours on the auth bypass, and it was frustrating. My head filled up with the obvious thoughts: this is it, I’m going to have to retake, and if I retake will I even pass next time, how does anyone pass this thing. What got me out of it was reorganising my thinking. I took breaks, kept asking myself where an auth bypass would actually start, went through all the authentication source, and eventually something looked off. I dug into it until I understood why it was off. That also meant I went down a few rabbit holes I’d rather not relive.

The one-shot exploit

OSWE wants a single script that chains the whole thing end to end. My pre-written Python from the labs mostly carried over, which is exactly why preparing it ahead of time matters so much. Under exam pressure the adjustments were mostly in how requests were handled rather than writing anything from scratch.

The report

Mine came out to around 50 pages, including the full Python exploit script, on OffSec’s standard template. Same reporting habits as my OSEP write-up carried over.

Worth it?

Yes, definitely, especially if you’re a security engineer or practitioner. I’ll be honest about the caveat though: most real source-code-review engagements out there are run mainly through commercial scanners like OpenText Fortify or SonarQube, not by hand. Where OSWE pays off is that it teaches you to actually understand a vulnerability: what you’re looking at, and how it comes together as a bug in the first place. That understanding is what the scanners can’t give you, and it’s worth the pain.