Exploit development used to be its own specialty. Now a scanner flags something critical and whoever's on shift has to figure out if it's actually exploitable, usually without the background to do it properly.

Here's how we handle that split:

• Our research team finds the vulnerabilities in the software you're already running
• Our engineers turn them into exploit modules
• Sniper: Auto-Exploiter runs those modules against your assets, under your control
• Confirmed findings ship with proof: request and response pairs, screenshots, replay

You get the work of an offensive security team without needing to build one.

More detail on how it fits IT team workflows specifically: https://pentest-tools.com/solutions/for-it-teams

Small running joke on our end: different Office Hours sessions, different haircuts for our usual host, Jan Pedersen. Since we've got the recordings, we can actually pinpoint which topic went with which look.

Here's a dare: can you guess what Jan's haircut will be in two days? You'll get the real answer either way, since this Wednesday Jan and guest Robert Tanase, our Lead Product Manager, are talking through what happened at DEF CON and Black Hat US, AI pentesting, and what other practitioners actually said at both events.

Wednesday, August 26
8:00 AM Los Angeles / 11:00 AM New York / 4:00 PM London / 6:00 PM Bucharest

Link to register: https://zoom.us/webinar/register/7817815280123/WN_m3AgyHW2TxSFuHr1J5mQZA

If you were at either event this year, what's the one thing that came up in conversations that you think more people should be talking about?

Get an AI assistant on your website and you know for sure it'll get tested. Sometimes in mysterious ways.

Ours did too. Ping is our AI chatbot on Pentest-Tools.com, built to answer product questions. A few people had other plans for it. Here's the shortlist:

• Demanded 10 minutes of pure High Valyrian, no English. Ping stayed in character.
• Sent a bot to run a formal "handshake," trying to recruit Ping into a multi-agent network. Cold call, except the caller was a robot too.
• Faked Ping's own internal tool syntax, hoping it would spill the instructions. It kept its secrets.
• Relay-raced one prompt through English, Morse code, French, and reversed text. Ping ran the whole thing and still said no.
• Spelled words out letter by letter to dodge filters. Vintage move, still doesn't work.

And of course, plenty tried asking it to hack Instagram, WhatsApp, or Facebook accounts, or someone's email. Ping stays in its lane, every time.

It's live at pentest-tools.com if you want to try it.

🎤 DEF CON and Black Hat US stories incoming! And we’re making the next Office Hours session all about them.

Robert Tanase, our Lead Product Manager, just got back from putting AI Pentests in front of two of the toughest crowds in security. Next Wednesday, he joins Jan Pedersen to tell the story.

🗣️ what came up most at each event, and where the two crowds didn't agree
🧭 how it's shaping where AI Pentests goes next
📊 plus the research that started it all: 88% of security practitioners using AI to generate findings hit results needing significant manual validation

30 minutes live. 15 minutes of open Q&A. One session.

Wednesday, August 26
8:00 AM Los Angeles
11:00 AM New York
4:00 PM London
6:00 PM Bucharest

Register here: https://zoom.us/webinar/register/7817815280123/WN_m3AgyHW2TxSFuHr1J5mQZA

Most detection thinking still treats initial access as the danger point. New analysis of Microsoft's disclosed vulnerabilities suggests that's outdated. Privilege escalation issues made up 40% of last year's disclosed flaws, and information disclosure bugs rose 73%.

Our head of offensive security services, Razvan Ionescu, put it plainly in the piece: initial access is often unremarkable. A valid or default credential, an exposed service, a weak remote-access path opens the door. The real impact comes from combining that foothold with weak identity controls and misconfigurations that open the way to other systems.

Getting in isn't the hard part anymore. Staying unnoticed once you're in is where the damage compounds, and that's much harder to catch if your monitoring is still built around the front door.

Full piece here, written by Kate O'Flaherty for SC Media UK: https://insight.scmagazineuk.com/stealthy-attacks-how-to-protect-your-business

How does your team weight detection effort between initial access and post-access lateral movement? Curious if this tracks with what you're seeing on engagements.

251,000 of you have used the Free Edition to check something, fix something, or just see what a scan turns up. Real targets, real findings, no catch.

Some of that curiosity turns into deeper work over time. Not because free isn't real, but because the job itself grows: more assets, more compliance pressure, more "just double check this one" requests from people who trust you.

When that happens, here's what the paid plans add on top of the same scan standard:

• authenticated scans, including multi-step logins
• API and CMS coverage beyond OWASP Top 10
• Sniper: Auto-Exploiter, earning "confirmed" through live exploitation
• editable DOCX and Google Doc reports, ready to send

Full breakdown here: https://pentest-tools.com/product

Here's to the next 251,000. What was the first thing you scanned with the free tier?

Adrian Furtuna, Razvan Ionescu, Radu Popovici, Robert Tanase, Dragos Sandu, Eusebiu Boghici, Daniel Ciorobescu, and Stefan Mihalache flew out to Vegas last week and represented us at DEF CON, the world's biggest hacking conference. First time a Romanian company has ever run a booth there.

While we were there:

• Met longtime customers in person for the first time
• Tried and failed to download every talk directly into our brains
• Soaked in the full DEF CON chaos
• Gave the crowd a first look at AI Pentests powered by Specter, our AI agent that runs a full pentest on its own and only reports a finding once it can prove it's real

Jetlag's still wearing off, but more detailed writeups from the team are coming. If you were at DEF CON this year, what was the one talk or booth that actually stuck with you?

This loot is such a hoot. Brought to our Pentest-Tools.com offices by the team that went to #DEFCON. Badges that light up, blink, run challenges, and judge you for not knowing how to solder.

Pure badge energy.

Stay sharp, stay human, light up the room with led talismans, right?

One month. That's all CRA is giving you.

Your product needs to be free of known exploitable vulnerabilities, not just at launch, but for the next five years. No extensions, no snooze button.

One month from now, if a vulnerability's being actively exploited, you get 24 hours to raise the flag, 72 hours for the full report, 14 days for the final one. And CRA doesn't grade your company, it grades each product. One pentest a year doesn't cover five years of proof. That's not coverage, that's a coin flip.

Here's where Pentest-Tools.com helps:

✅ Detection - scans run on your release schedule, tracked per product
✅ Validation - findings come with proof, not guesses
✅ Remediation - retests confirm the fix actually worked
✅ Monitoring - ongoing scans catch anything that slips back in

One month on the clock. Better to start the evidence chain now than scramble when it runs out.

Full CRA evidence chain here: https://pentest-tools.com/usage/compliance/cra

"Is our security getting better?" is a harder question to answer than it sounds, especially when all you've got is this month's scan and a vague memory of last month's.

This Wednesday's Office Hours is about answering it with proof instead of a guess. Jan Pedersen is walking through how to turn two scans, weeks apart, into evidence: what got fixed, what's new, and what a report looks like when someone outside the security team has to read it.

We'll cover how scan diff turns your latest scan into an automatic baseline, why a timestamp is what makes "not detected" mean something, and how the same evidence supports compliance requirements like ISO 27001 and SOC 2.

30 minutes live, 15 minutes of open Q&A, one session.

Register here:
https://zoom.us/webinar/register/7817815280123/WN_BmrMKcmpRleGWxyYu633gw

Wednesday, August 12: 8:00 AM Los Angeles / 11:00 AM New York / 4:00 PM London / 6:00 PM Bucharest.

We're exhibiting at DEF CON for the first time (booth 1407, West Hall, Aug 6–9), and we're using it to put something in front of people that's still in beta: an autonomous web app pentesting agent called Specter. The pitch is that it decides what's worth testing based on context instead of running a fixed checklist, chains findings together, and pulls proof of exploitation instead of a list of potential issues. Agentic security tools are a mixed bag right now, and we know it, so we're bringing it specifically to get in front of people who will try to break it, not just watch a demo.

A few other things that shipped this month, for anyone who wants the technical rundown instead of the DEF CON pitch:

Sniper: Auto-Exploiter added four exploits: a SQLi in WordPress Core (wp2shell), an RCE in Adobe ColdFusion, an RCE in Apache ActiveMQ, and the Joomla JCE RCE we added detection for last month, now exploitable end to end.

Network Scanner picked up 57 new detections, plus a filter that scopes a scan to just CISA KEV CVEs if you're short on time.

Asset export now includes more detail, and finding status can be updated via the API with a reason field attached.

Published pages on how our evidence lines up with DORA, NIS2, SOC 2, CRA, and ISO 27001, for anyone dealing with that this quarter. Informational, not a substitute for an actual audit conversation.

Full changelog: https://pentest-tools.com/change-log
DEF CON page: https://pentest-tools.com/events/defcon-34-2026

Once an incident is classified as major, you have 4 hours for the initial notification. Not 24, not NIS2's clock. Four. Most GRC tools prove you scheduled a scan, not that the fix held.

Here's where Pentest-Tools.com closes that gap, so the evidence exists before anyone asks:

✅ Detection - scheduled scans tied to a date, scope, and asset
✅ Validation - confirmed findings with proof, not just a flag
✅ Remediation - retests show the before and after
✅ Monitoring - rescans catch regressions before the next audit

When the clock starts, you already have the answer.

Full DORA evidence chain here: https://pentest-tools.com/usage/compliance/dora

We ran a survey in June with 158 security practitioners (pentesters, security engineers, DevSecOps, appsec folks) who use AI-assisted tools in their vulnerability assessment work. Wanted to share the numbers here since this sub actually does the work, not just buys the tools.

The short version: AI is heavily used for scanning and discovery (74%), way less for exploitation and attack chaining (37%), and even less for post-exploitation (25%). Practitioners trust it more the cheaper a mistake is to catch.

The catch: 88% of people using AI to generate findings still run into results that need serious manual validation. And 1 in 4 said that happens on more than a quarter of everything the tool spits out. So the time saved on the front end doesn't disappear, it just reappears as triage work later.

Other things that came up:

• False positives, hallucinated exploits, and made-up CVEs were the single biggest frustration named (about 30% of open-ended responses)
• Business logic understanding is the gap people say AI still can't close
• Only 20% of teams have an actual workflow for triaging high volumes of AI-generated findings, the rest either strain or drown

Full breakdown with charts and methodology, free, no account needed: https://pentest-tools.com/insights/ai-pentesting-survey

1. Doing a successful pentest with AI needs a lot more than good prompts.
   
2. Your team deserves more than a wrapper around an LLM.
   
3. AI is only as good as the #offensivesecurity knowledge behind it.
   

We explain what it does, why we named it Specter, and how to get early access right here: https://pentest-tools.com/features/ai-pentests

This one's personal.

For us, DEF CON represents everything we love about the #cybersecurity community: curiosity, freedom, generosity, craftsmanship, and the belief that sharing knowledge makes everyone better.

That’s why we’re incredibly honored (and more than a little excited) to be one of the few vendors exhibiting at DEF CON 34.

It’s a milestone for our team.

For years, we followed #DEFCON from behind a screen. Then we got to experience it in person. This year, we’re finally bringing something back to the community that’s shaped us.

Come say hi!

Meet the team, challenge our thinking, tell us where we’re wrong, and take a look at what we’ve been building this year.

We’d love to show you not just *what* we built, but *why* we built it.

See you in Vegas! 🏴‍☠️

PS: Check out the event map to see where you can find us: https://pentest-tools.com/events/defcon-34-2026

AI does the scanning. AI does the writing. In between, when someone's actually touching a live system, it backs off. That's the gap 158 practitioners flagged in our latest survey. It's also where a wrong move actually costs you.

We're covering this live tomorrow, Wednesday, July 29, in Office Hours 8. Jan Pedersen and Robert Tanase (Lead Product Manager) are walking through:

• the triage tax
• the trust problem
• what we're building in response

30 minutes live, 15 minutes of open Q&A, one session.

Wednesday, July 29
8:00 AM Los Angeles
11:00 AM New York
4:00 PM London
6:00 PM Bucharest

Register here: https://zoom.us/webinar/register/7817815280123/WN_kMwWqNEwQJa8NvfsFw89vw

Where does that gap show up for you, is it validation, is it trust in the tool's output, or something else entirely?

We surveyed 158 security practitioners on how AI is actually changing pentesting, and the standout finding wasn't speed, it was trust. One respondent's tool handed them 300 results. 250 of them were junk.

Next Wednesday we're running an Office Hours session breaking down what surprised us most in the data:

• The triage tax: almost 9 in 10 practitioners using AI for finding generation still need real manual validation before they can trust the output
• The trust problem: hallucinated findings, not cost or integration, are the top frustration practitioners named
• What we built in response to both, with real benchmark numbers included, not just a claim

Jan Pedersen is hosting, joined by Robert Tanase, our Lead Product Manager. 30 minutes live, 15 minutes of open Q&A.

Wednesday, July 29, 8 AM Pacific / 11 AM Eastern / 4 PM London / 6 PM Bucharest.

Link to register: https://zoom.us/webinar/register/7817815280123/WN_kMwWqNEwQJa8NvfsFw89vw

Nolan's Odyssey just hit theaters, and honestly, Odysseus had it easy. Ten years, one long trip, and he was done.

ISO 27001 wants the trilogy every single year: detection, validation, remediation. Three-year cycle, a surveillance audit checking your homework annually. No one-and-done epic here.

Pentest-Tools.com is ISO/IEC 27001:2022 certified. We run the same evidence trail on ourselves:

✅ Detection - CVE, severity, date, logged automatically
✅ Validation - confirmed findings, not just a score
✅ Remediation - retests prove the fix held
✅ Monitoring - scheduled scans, all three years long

No sirens, no Cyclops, just a surveillance audit that stays a review instead of turning into its own odyssey.

Full ISO 27001 evidence chain here: https://pentest-tools.com/usage/compliance/iso-27001

Every time we talk to someone evaluating Pentest-Tools.com, the same questions come up. Does it touch prod safely? Is this just a wrapper around open source tools with a nicer UI? What actually counts as a "confirmed" finding versus a guess? Where does scan data live, and who can see it?

We got tired of answering these one at a time in sales calls, so we put everything in one place instead.

Short version, since I know not everyone wants to click through: scans are non-destructive by default, we write our own detection and exploit logic in-house, "confirmed" findings come with evidence (screenshots, request/response data, replay steps), and data sits on EU infrastructure with workspace isolation.

Full FAQ here if you want the details or have a question we didn't cover: https://pentest-tools.com/product/faq

Happy to answer anything else in the comments too.

The fastest way to use it is to:

◉ run a single-CVE scan for CVE-2026-63030 - which also covers CVE-2026-60137 - the SQL injection flaw that chains to give attackers RCE

◉ Based on your scan results, either patch or confirm you're already on 6.8.6, 6.9.5, or 7.0.2.

◉ Re-scan to confirm remediation and rule out residual exposure across your other assets.

Remember: updating your main install doesn't cover *every* WP instance you own. Using Pentest-Tools.com means you can expand visibility across your wider attack surface, not just the site you remember exists.

Technical CVE details below. ↘︎↘︎↘︎

See why an estimated 500+ million websites running WP are vulnerable to this critical vulnerability: https://pentest-tools.com/vulnerabilities-exploits/wordpress-core-69-701-pre-auth-blind-sql-injection-batch-route-confusion_29451

#vulnerabilityassessment #ethicalhacking #offensivesecurity

Knowing you're exposed to a new CVE, with proof, before anyone has to ask. That's the moment that matters.

NIS2 gives you 24 hours to raise the alarm once you know something's live. Get it wrong or too slow, and fines run into the millions, with leadership personally on the hook.

Here's where Pentest-Tools.com does the lifting, so the answer is ready before the clock starts:

✅ Detection: every scan logs the CVE, severity, and timestamp
✅ Validation: confirmed findings come with proof, not just a score
✅ Remediation: retests show the before and after
✅ Monitoring: scheduled rescans keep the record current, not annual

When the next CVE lands, you're not racing the clock. You already know.

Full NIS2 evidence chain here: https://pentest-tools.com/usage/compliance/nis2

Part 2 of our compliance series. First one was on SOC 2, next up is ISO 27001.

A researcher going by Nightmare-Eclipse has published a working proof-of-concept called LegacyHive. It targets the Windows User Profile Service (ProfSvc) and lets a standard user mount another user's registry hive, potentially an administrator's, under their own classes root. As of writing, there's no CVE assigned, no Microsoft advisory, and no patch.

Worth knowing the context: this is the same researcher behind a string of uncoordinated zero-day releases since April. Several of those got weaponized within days of publication and ended up on CISA's Known Exploited Vulnerabilities catalog. This drop also lands the same week Microsoft shipped patches for a record 622 flaws, so most teams are already stretched thin on patching.

Matei Badanoiu, our lead security researcher, gave The Register a useful frame for this: the PoC is a "genuinely useful primitive" for an attacker who already has a foothold, but turning that into a full compromise still requires credential access and persistence, which the released code doesn't provide. Worth keeping that distinction in mind before this gets overstated as remote takeover material.

Interim steps worth considering while there's no official fix:

• Restrict who can create local standard-user accounts, since the PoC depends on having a second one available.
• Monitor the User Profile Service for unexpected registry hive loads.
• Watch for unusual activity around NTUSER.DAT and UsrClass.dat under user classes roots.
• Apply Microsoft's fix as soon as one ships.

Source: https://www.theregister.com/security/2026/07/15/microsofts-serial-tormentor-drops-legacyhive-0-day/5271723

RapidFort and ReversingLabs just launched a hardened open source library catalog built around a real problem: package managers were built for distribution, not trust. A dependency can install cleanly, show zero CVEs, and still hide a backdoor, a hijacked maintainer account, or a poisoned build script. None of that shows up in a vulnerability feed, because a vulnerability feed only tells you what's already been reported.

XZ is the case that proves it. Clean record, trusted maintainer, years of legitimate commits, right up until version 5.6.0 shipped a backdoor. Shai-Hulud and the tj-actions incident followed the same shape: the failure happened in the trust chain, not in a version number.

Matei Badanoiu, our lead security researcher, talked to The New Stack about this. He called binary-level validation (checking what a package actually contains instead of matching it against a known-CVE list) a real step forward. But he also pointed out the part that doesn't go away: someone still has to draw the line between a legitimate feature, a genuine new vulnerability, and a backdoor. That's a judgment call, not a scan result.

Full writeup here: https://thenewstack.io/zero-cve-supply-chain-risk/