If you run a WordPress site, WP2Shell is the vulnerability you cannot afford to ignore. Tracked as CVE-2026-63030 and chained with the SQL injection flaw CVE-2026-60137, it lets a completely anonymous attacker — no login, no plugin, no special setup — run their own code on your server. WordPress powers over 500 million sites, and public exploit code is already circulating, so the only question that matters right now is a simple one: is my version exposed?

The free checker above answers that instantly. Type in your WordPress version (you'll find it under Dashboard → Updates, or in the bottom-right corner of any wp-admin screen) and it tells you immediately whether you are in the vulnerable range.

WP2Shell (CVE-2026-63030): Checker, Patch & Detection Guide

It flags the full remote-code-execution risk for versions 6.9.0–6.9.4 and 7.0.0–7.0.1, the SQL-injection-only exposure on the 6.8 branch and confirms when you are safely on a patched build (7.0.2, 6.9.5 or 6.8.6).

Everything runs entirely inside your own browser. Nothing you type is uploaded, stored, or logged — there is no server, no tracking, and no database on our end. You can also switch to the “Check a site URL” tab to look up the WordPress version of a site you own or are authorised to test.

This tool is built for site owners, administrators and security researchers who need a fast, no-nonsense answer. Remember: the checker tells you your risk — the fix is to update WordPress immediately. Once you've checked, scroll down for the full patch steps, WAF rules, detection scripts and indicators of compromise.

Point it at an authorized target and the kill chain runs itself: recon → exploit → report, from a browser War Room or the CLI, driven by the agent you’re already signed into — Claude Code, Codex, Hermes — or a model you run fully offline (Ollama, LM Studio, vLLM). No new API keys, no cloud tenant, no second bill. Your agent is the brain; T3MP3ST is the war machine bolted around it. Self-hosted storm. Keyless warfare. ⚡

And it won’t ask you to take its word for it. On XBOW’s own 104-challenge suite it scores 90.1% pass@1 — above XBOW’s self-reported 85% — alongside hint-free CTF solves and a cold hunt on real, post-cutoff CVEs the model had never seen. Every number in this README recomputes from committed data with one command (npm run verify-claims). Loud about the mission, honest about the build — the status table says exactly what’s live, what’s scaffolding, and what’s still roadmap; full receipts in Benchmarks.

Three things set it apart:

Reproducible. Every number in this README recomputes from committed data — npm run verify-claims re-derives all of them, 24/24 green. A claim that can’t be reproduced doesn’t ship. No trust-me numbers, ever.
Keyless. The AI coding agent already on your machine is the backbone. No API keys, no second bill, no gatekeeper.
Honest about scope. The status table marks exactly what’s stable, experimental, or roadmap — because red-teaming shouldn’t be a priesthood, and it damn sure shouldn’t run on vibes.

⚠️ Authorized use only T3MP3ST is an offensive security tool, built for authorized testing, research, and education. Point it only at systems you own or have explicit, written permission to test. Unauthorized access to computers, networks, or data is illegal in most jurisdictions — you alone are responsible for how you use this software and for staying inside the law and your rules of engagement. Bring the storm to your targets, not someone else’s.
T3MP3ST is provided as-is under the AGPL-3.0 license, with no warranty and no liability for any damage, loss, or misuse. The authors do not endorse, support, or condone unauthorized activity. Get permission. Stay in scope. Don’t be a menace. 🫡

Quick start

Fastest path to a running War Room (keyless, ~2 min to set up; mission time depends on the target):

npm install
npm run server        # War Room → http://127.0.0.1:3333/ui/

SightHouse is an open-source tool developed by Quarkslab that helps reverse engineers automatically identify known functions inside binaries by matching them with previously analyzed code.

SightHouse is a tool designed to assist reverse engineers by retrieving information and metadata from programs and identifying similar functions.

What Problem Does It Solve?

Reverse engineering modern software is complex due to:

• Large codebases with thousands of functions
• Heavy use of third-party libraries
• Repetitive or AI-generated code patterns

This makes it difficult to distinguish custom logic vs reused components, often wasting time analyzing irrelevant code.

SightHouse tackles this by automating function identification using similarity matching.

Deployment & Usage

SightHouse is available on Pypi.

# Install SRE clients only
pip install sighthouse-client 
# Install frontend only
pip install sighthouse-frontend
# Install pipeline only 
pip install sighthouse-pipeline
# Or install everything
pip install sighthouse[all]

From sources

You can also install it from the git repository:

# Download the repo
git clone https://github.com/quarkslab/sighthouse && cd sighthouse 
# Make install will create a new virtual env and install sighthouse in it
make install 

How SightHouse Works

SightHouse compares functions from a target binary with a large database of known function signatures. When a match is found:

• The function is identified
• Its original name and source are suggested
• Metadata is added directly inside the reverse engineering tools

It supports integration with:

• IDA Pro
• Ghidra
• Binary Ninja

Core Technology

SightHouse relies on the Binary Similarity problem, which involves detecting similar functions using:

• Assembly code
• Intermediate representations
• Raw binary patterns

After benchmarking multiple approaches, the tool uses BSIM (from Ghidra) as its core engine because:

• It is scalable
• Works across architectures
• Supports large databases via PostgreSQL/Elasticsearch
• Provides stable performance for production use

Architecture Overview

SightHouse is built with three main components:

1. SRE Clients (Plugins)
   • Integrated into tools like Ghidra/IDA
   • Sends binaries for analysis
2. Frontend API Server
   • Central system handling requests
   • Runs analysis using Ghidra + BSIM
3. Signature Pipeline
   • Automatically builds and updates the signature database
   • Scrapes projects, compiles them, and extracts function signatures

👉 The diagram on page 3 shows this pipeline workflow, including scrapers, compilers, analyzers, and storage systems working together.

CISO Assistant offers a fresh perspective on Cybersecurity Management and GRC (Governance, Risk, and Compliance) practices:

• Designed as a central hub to connect multiple cybersecurity concepts with smart linking between objects,
• Built as a multi-paradigm tool that adapts to different backgrounds, methodologies, and expectations,
• Explicitly decouples compliance from cybersecurity controls, enabling reusability across the platform.
• Promotes reusability and interlinking instead of redundant work,
• Developed with an API-first approach to support both UI interaction and external automation,
• Comes packed with a wide range of built-in standards, security controls, and threat libraries,
• Offers an open format to customize and reuse your own objects and frameworks,
• Includes built-in risk assessment and remediation tracking workflows,
• Supports custom frameworks via a simple syntax and flexible tooling,
• Provides rich import/export capabilities across various channels and formats (UI, CLI, Kafka, reports, etc.).

Features

Upcoming features are listed on the roadmap.

CISO Assistant is developed and maintained by Intuitem, a company specializing in Cybersecurity, Cloud, and Data/AI.

Core Concepts

Here’s an extract of some of the building blocks in CISO Assistant to illustrate the decoupling concept that encourages reusability:

System architecture

AndroHunter is a native Android application that provides a full suite of mobile security testing tools — all running directly on the device without requiring a rooted phone for most features. It is designed for security researchers participating in bug bounty programs (HackerOne, Yes We Hack, Intigriti, etc.) who need to analyze Android applications quickly and efficiently.

The tool covers the entire Android attack surface: static analysis (APK, DEX, Manifest), dynamic testing (Intent fuzzing, ContentProvider probing, Broadcast injection), runtime analysis (Frida script generation, SSL bypass), and network interception (HTTP proxy).

AndroHunter is intended for authorized security research, bug bounty programs, and educational purposes only. You must have explicit permission from the application owner before testing any target. The developer assumes no responsibility for misuse. Always comply with your bug bounty program’s scope and rules of engagement.

Features

📱 App Explorer

• Lists all installed applications with metadata (package name, version, permissions, target SDK)
• Filter by system/user apps
• Quick navigation to any analysis module from the app detail view

🔍 DEX Analyzer

• Extracts and analyzes .dex files from APKs
• Scans for hardcoded secrets: API keys, tokens, passwords, URLs, private keys
• String pattern matching with severity classification (VULN / SUSP / SAFE)
• Class and method enumeration with popup viewer
• Supports multi-dex APKs — each DEX file analyzed separately

📄 Manifest Viewer

• Parses AndroidManifest.xml directly from the APK (no decompiler needed)
• Three-tab view: Components, Permissions, Raw XML
• Highlights exported components, dangerous permissions, and deep link schemes
• Identifies potential attack surface (exported Activities, Services, Receivers, Providers)

🎯 Intent Fuzzer

• Lists all exported Activities, Services, and Broadcast Receivers of the target app
• Sends crafted Intents with custom extras, data URIs, and categories
• Supports path traversal payloads via Intent data (file:///data/...)
• Integrates with Payload Engine for automated testing

💥 Payload Engine

• Logcat-based real-time result monitoring
• Automated payload delivery to target components
• Visual result classification: VULN (red) / SUSP (yellow) / SAFE (green)
• Supports deeplink exploitation, OAuth redirect hijacking, file URI leaks

🗄️ Content Provider Fuzzer

• Enumerates all exported ContentProviders of the target application
• Tests 9 SQL injection payloads per provider (Error-based, Boolean, UNION, Time-based)
• Detects readable/writable providers and schema exposure
• One-tap navigation from APK Analyzer findings to Provider Fuzzer with pre-filled target

📁 FileProvider Path Analyzer

• Parses res/xml/ configuration files from APK to extract FileProvider path definitions
• Risk classification per path type:
  • root-path with empty path → CRITICAL (full filesystem access)
  • external-path with empty path → HIGH
  • cache-path / external-cache-path → MEDIUM
• Path Traversal Tester: automated testing with 9 traversal payloads
• Attempts actual file reads via ContentResolver and reports file contents on success
• ADB Commands tab: ready-to-use adb shell content read --uri '...' commands

🏃 Activity Launcher

• Lists all Activities of any installed app with the exported status badge
• One-tap launch with optional extra data / deep link injection
• ADB command generator: adb shell am start -n pkg/activity --es data "payload"
• Filter by exported-only for quick attack surface identification

📡 Broadcast Fuzzer

• 10 pre-built broadcast payloads across 6 categories:
  • Auth: Login bypass, Session hijack
  • SQLi: SQL injection via Intent extras
  • LFI: Path traversal via file path extras
  • Redirect: Open redirect, Deep link hijack
  • PrivEsc: Privilege escalation, Component enable
  • Exfil: Data exfiltration via backup intent
• Custom broadcast sender: specify action + key=value extras
• ADB command copy for each payload

🔑 Shared Preferences Reader

• Reads shared_prefs/*.xml files from target application data directory
• Uses run-as for debug apps, falls back to dumpsys for others
• Sensitive key detection: token, password, secret, api_key, session, jwt, cookie
• Filter by sensitive-only, full text search, one-tap copy

🐛 Frida Script Generator

• Generates ready-to-use Frida hook scripts tailored to the selected target package
• 6 script categories:
  • SSL Pinning Bypass: OkHttp3, TrustManager, Conscrypt, BoringSSL
  • Root Detection Bypass: RootBeer, SafetyNet, File.exists() hook
  • Login Bypass: Auto-discovers auth/login/session classes via reflection
  • Crypto Monitor: Hooks javax.crypto.Cipher — logs all encrypt/decrypt operations
  • SQL Monitor: Hooks SQLiteDatabase.rawQuery, execSQL, query
  • HTTP Intercept: Hooks OkHttp3 and HttpURLConnection
• One-tap copy with or without launch command header
• Ready-to-run command: frida -U -f com.target.app -l script.js --no-pause

🔓 SSL Pinning Bypass Guide

• 6 bypass methods with step-by-step instructions:
  1. Frida SSL Kill Switch 2 — easiest, no root needed
  2. objection — android sslpinning disable
  3. Magisk TrustMeAlready — system-wide bypass
  4. APK Repack — inject network_security_config.xml via apktool
  5. Xposed / LSPosed + JustTrustMe
  6. Burp Suite + User CA

🌐 Traffic Interceptor

• Built-in HTTP proxy server running on 127.0.0.1:8877
• Captures HTTP traffic from any application configured to use the proxy
• HTTPS CONNECT tunnel support
• Real-time request/response list with method color coding
• Sensitive header highlighting: Authorization, Cookie, Token shown in red
• Per-request detail view: full headers, request body, response body, timing
• curl command generator: one-tap copy of any captured request
• Filter by URL, host, body content, or HTTP method

🖥️ Terminal

• On-device shell command execution
• Quick command chips: id, whoami, uname -a, env, ifconfig, netstat -an, ps, ls /data
• Color-coded output: commands (green), stdout (white), stderr (red)
• IME padding: input bar stays visible when keyboard opens

👁️ Broadcast Monitor

• Live monitor for system and custom broadcast intents

🎭 Task Hijack (StrandHogg)

• Tests for Task Affinity hijacking vulnerability (StrandHogg 1.0)

♿ Accessibility Monitor

• Monitors Accessibility Service events from target applications

Requirements

• Android 10+ (API 29+)
• No root required for most features
• Root / run-as: enables SharedPrefs reading on non-debug apps
• ADB over USB: required for ADB Manager commands
• Frida server on device: required for Frida script execution (scripts generated on-device, run from PC)

This project implements the research from the paper “Careless Whisper: Exploiting Silent Delivery Receipts to Monitor Users on Mobile Instant Messengers” by Gabriel K. Gegenhuber, Maximilian Günther, Markus Maier, Aljosha Judmayer, Florian Holzbauer, Philipp É. Frenzel, and Johanna Ullrich (University of Vienna & SBA Research).

What it does: By measuring Round-Trip Time (RTT) of WhatsApp message delivery receipts, this tool can detect:

• When a user is actively using their device (low RTT)
• When the device is in standby/idle mode (higher RTT)
• Potential location changes (mobile data vs. WiFi)
• Activity patterns over time

Security implications: This demonstrates a significant privacy vulnerability in messaging apps that can be exploited for surveillance.

⚠️ DISCLAIMER: The tool is for educational and security research purposes only. Demonstrates privacy vulnerabilities in WhatsApp and Signal.

Installation

# Clone repository
git clone https://github.com/gommzystudio/device-activity-tracker.git
cd device-activity-tracker

# Install dependencies
npm install
cd client && npm install && cd ..

Requirements: Node.js 20+, npm, WhatsApp account

Usage

Web Interface (Recommended)

# Terminal 1: Start backend
npm run start:server

# Terminal 2: Start frontend
npm run start:client

Open http://localhost:3000, scan QR code with WhatsApp, then enter phone number to track (e.g., 491701234567).

CLI Interface

npm start

Follow prompts to authenticate and enter target number.

Example Output:

╔════════════════════════════════════════════════════════════════╗
║ 🟡 Device Status Update - 09:41:51                             ║
╠════════════════════════════════════════════════════════════════╣
║ JID:        ***********@lid                                    ║
║ Status:     Standby                                            ║
║ RTT:        1104ms                                             ║
║ Avg (3):    1161ms                                             ║
║ Median:     1195ms                                             ║
║ Threshold:  1075ms                                             ║
╚════════════════════════════════════════════════════════════════╝

• 🟢 Online: Device is actively being used (RTT below threshold)
• 🟡 Standby: Device is idle/locked (RTT above threshold)
• 🔴 Offline: Device is offline or unreachable (no CLIENT ACK received)

How It Works

The tracker sends reaction messages to non-existent message IDs, which triggers no notifications at the target. The time between sending the probe message and receiving the CLIENT ACK (Status 3) is measured as RTT. Device state is detected using a dynamic threshold calculated as 90% of the median RTT: values below the threshold indicate active usage, values above indicate standby mode. Measurements are stored in a history and the median is continuously updated to adapt to different network conditions.

Common Issues

• Not Connecting to WhatsApp: Delete the auth_info_baileys/ folder and re-scan the QR code.

How to Protect Yourself

The most effective mitigation is to enable “Block unknown account messages” in WhatsApp under Settings → Privacy → Advanced.

This setting may reduce an attacker’s ability to spam probe reactions from unknown numbers, because WhatsApp blocks high-volume messages from unknown accounts. However, WhatsApp does not disclose what “high volume” means, so this does not fully prevent an attacker from sending a significant number of probe reactions before rate-limiting kicks in.

Disabling read receipts helps with regular messages but does not protect against this specific attack. As of December 2025, this vulnerability remains exploitable in WhatsApp and Signal.

What is PyXL?

PyXL is a custom hardware processor that executes Python directly — no interpreter, no JIT, and no tricks. It takes regular Python code and runs it in silicon.

A custom toolchain compiles a .py file into CPython ByteCode, translates it to a custom assembly, and produces a binary that runs on a pipelined processor built from scratch.

It’s a real processor for Python, built for determinism and speed.

Where does it run?

PyXL runs on a Zynq-7000 FPGA (Arty-Z7-20 dev board). The PyXL core runs at 100MHz. The ARM CPU on the board handles setup and memory, but the Python code itself is executed entirely in hardware.

The toolchain is written in Python and runs on a standard development machine using unmodified CPython.

What is a GPIO?

GPIO stands for General Purpose Input/Output. It’s a simple hardware pin that software can read from or write to — a way to control the outside world: LEDs, buttons, sensors, motors, and more.

In MicroPython (like on the PyBoard), your Python code interacts with C functions that handle hardware registers underneath. It’s reasonably fast, but still goes through a Python VM and a software stack before reaching the pin.

PyXL skips all of that. The Python bytecode is executed directly in hardware, and GPIO access is physically wired to the processor — no interpreter, no function call, just native hardware execution.

The program

from compiler.intrinsics import *


def main():
    pyxl_write_gpio_pin1(0)              # Reset output pin

    c1 = pyxl_get_cycle_counter()        # Cycle counter (100 MHz)

    pyxl_write_gpio_pin1(1)              # Set output pin
    while pyxl_read_gpio_pin2() == 0:    # Wait until input pin is set to 1
        continue

    c2 = pyxl_get_cycle_counter()        # Cycle counter (100 MHz)

    return (c2 - c1) * 10                # Return result in nano seconds (each cycle is 10 ns)

As you can see, this is a regular Python program, but it also has some unfamiliar function calls. These functions originate from compiler.intrinsics module.

pyxl_get_cycle_counter()

Gets the current cycle counter from the PyXL CPU. This counter advances by 1 on every tick

pyxl_write_gpio_pin1()

Writes a value (0/1) to a GPIO pin. These are low-level intrinsics exposed by the compiler — currently hardcoded for this test, but will evolve into a more general pyxl_gpio_write(pin, value) API.

pyxl_read_gpio_pin2()

Reads the value from Pin2. The same API comment is true here as well.

How does it work?

As described above, the program is compiled using a CPython Bytecode and then recompiled using PyXL assembly. It is then linked together, and a binary is generated.

This binary is sent via network to the Arty board, where an ARM CPU gets the application, copies it to a shared memory with the PyXL HW, and starts running it.

A typical Python runtime (CPython or MicroPython in case of the PyBoard or Python for embedded in general) has a big overhead caused by running the ByteCode on a software-based VM. In PyXL, there’s no VM; the HW does everything.

As for reading and writing the GPIO, the GPIO headers are directly mapped to FPGA pins, and physically wired into PyXL’s core top-level module. Think of it as the main function of the HW.

In this test, all code and data reside in predictable, low-latency memory, ensuring deterministic behavior (real-time behavior). This means that for the same input, it’ll take the exact same time to run.

PyXL

CF-Hero is a comprehensive reconnaissance tool developed to discover the real IP addresses of web applications protected by Cloudflare. It gathers multi-source intelligence through various methods.

DNS Reconnaissance

• Current DNS records (A, TXT)
• Historical DNS data analysis
• Associated domain discovery

Intelligence Sources

• Active DNS enumeration
• Censys search engine
• Shodan search engine
• SecurityTrails historical records
• Related domain correlation

The tool analyzes data from these sources to identify potential origin IP addresses of Cloudflare-protected targets. It validates findings through response analysis to minimize false positives.

Features

DNS Reconnaissance

• Checks current DNS records (A, TXT)
• Extracts domains behind Cloudflare
• Extracts domains not behind Cloudflare

Third-party Intelligence

• Censys integration
• Shodan integration
• SecurityTrails integration
• Reverse IP lookup for associated domains

Advanced Features

• Custom JA3 fingerprint support
• Concurrent scanning capabilities
• Standard input support (piping)
• HTML title comparison for validation
• Proxy support
• Custom User-Agent configuration

OSINT

OSINT is another technique to find the real IP of any domain that is behind CloudFlare. There are lots of unique search engines for special purposes. Shodan and Censys are two of these. They provide more detail and technical information. 

These search engines continuously scan the whole internet and discover new assets or monitor and log asset changes. When a domain not behind Cloudflare gets up, both engines can log the domain’s real IP. After a while, if the domain takes behind Cloudflare, their IP can be found using these search engines.

CF-Hero checks censys and shodan too. (Note that when you use these services, you have some limits due to API quotas.)

(Sub)Domains

The other trick is the (sub)domain technique. Actually, It doesn’t have to be a subdomain.n It can be domain as well. The key point is here; domains should belong to the same company.

Let’s say we have 2 domains. One of them is behind Cloudflare, but the other is not. In this case, you connect to the domain, not the one behind Cloudflare, and then change the host header to the domain behind Cloudflare. If you get a response from applications behind Cloudflare, congratulations, you bypassed Cloudflare. You cannot access web applications from IP directly anymore. (and of course,e that also depends on the configuration)

Installation Instructions

cf-hero requires go1.18 to install successfully. Run the following command to install.

go install -v github.com/musana/cf-hero/cmd/cf-hero@latest

Usage:

 cf-hero [flags]

Check CF-Hero

HExHTTP is a tool designed to perform tests on HTTP headers and analyze the
results to identify vulnerabilities and interesting behaviors.

Features

• Server Error response checking
• Localhost header response analysis
• Vhosts checking
• Methods response analysis
• HTTP Version analysis [Experimental]
• Cache Poisoning DoS (CPDoS) techniques
• Web cache poisoning
• Range poisoning/error (416 response error) [Experimental]
• Cookie Reflection
• CDN/proxies Analysis (Envoy/Apache/Akamai/Nginx) [IP]

Installation

Python

pip install -r requirements.txt 
./hexhttp.py -u 'https://target.tld/'
# OR
python3 hexhttp.py -u 'https://target.tld/''

Docker

docker build -t hexhttp:latest .
docker run --rm -it --net=host -v "$PWD:/hexhttp/" hexhttp:latest -u 'https://target.tld/'

Usage

  Usage: hexhttp.py [-h] [-u URL] [-f URL_FILE] [-H CUSTOM_HEADER] [-A USER_AGENT] [-F] [-a AUTH] [-b]

HExHTTP is a tool designed to perform tests on HTTP headers.

options:
  -h, --help            show this help message and exit
  -u URL, --url URL     URL to test [required]
  -f URL_FILE, --file URL_FILE
                        File of URLs
  -H CUSTOM_HEADER, --header CUSTOM_HEADER
                        Add a custom HTTP Header
  -A USER_AGENT, --user-agent USER_AGENT
                        Add a custom User Agent
  -F, --full            Display the full HTTP Header
  -a AUTH, --auth AUTH  Add an HTTP authentication. Ex: --auth admin:admin
  -b, --behavior        Activates a simplified version of verbose, highlighting interesting cache behaviors
  -hu HUMANS, --humans HUMANS
                        Performs a timesleep to reproduce human behavior (Default: 0s) value: "r" or "random"
  -t THREADS, --threads THREADS
                        Threads numbers for multiple URLs. Default: 10
  -l LOG, --log LOG     Set the logging level (DEBUG, INFO, WARNING, ERROR, CRITICAL)
  -L LOG_FILE, --log-file LOG_FILE
                        The file path pattern for the log file. Default: logs/
  -v, --verbose         Increase verbosity (can be used multiple times)

Check HExHTTP