Web security tools: check your TLS, look up CVEs and log what a page requests

TL;DR: To check your site's TLS configuration, run sslscan your-site.example (or ask HackerGPT to "perform an SSL scan" on it) and look for anything older than TLS 1.2, weak ciphers and the certificate's expiry date. To learn whether a known CVE affects you, look the CVE up in NVD, compare its affected version ranges with the versions you actually run, and remember that a version match is a lead, not a confirmed finding. To see the API calls a page makes, load it in a browser with network logging: on CyberGym a plain fetch showed none, and the browser logged 17.

This page is the reference for HackerGPT's web security tools: the SSL/TLS scanner, the CVE lookup and search tools, the WordPress scanner, and the browser with network logging. Each section answers the question you would bring to it, shows the prompts that run it, and, for the three core tools, shows real output from a run on 24 October 2026 against CyberGym, our deliberately vulnerable practice target built on OWASP Juice Shop. Use these tools only on sites you own or have written permission to test.

How do I check my site's TLS configuration?

Scan the site's HTTPS port with a TLS scanner and read three things from the output: which protocol versions it accepts, which cipher suites it offers, and when the certificate expires. Anything below TLS 1.2 should be off: RFC 8996 formally deprecated TLS 1.0 and 1.1 in March 2021.

SSL/TLS Security Analysis

HackerGPT's SSL scan runs sslscan against the domain you name and returns the supported protocols, the cipher suites and key exchange groups, checks such as Heartbleed, and the certificate details. Prompts that run it:

Perform SSL Scan on cybergym.hackergpt.app
Check the SSL configuration of your-site.example
Is your-site.example vulnerable to heartbleed?
What TLS versions does your-site.example support?

The same scan by hand is one command. This is the real output of sslscan 2.2.3 against CyberGym on 24 October 2026, shortened where marked:

$ sslscan --no-colour cybergym.hackergpt.app
Testing SSL server cybergym.hackergpt.app on port 443 using SNI name cybergym.hackergpt.app

  SSL/TLS Protocols:
SSLv2     disabled
SSLv3     disabled
TLSv1.0   disabled
TLSv1.1   disabled
TLSv1.2   enabled
TLSv1.3   enabled

  TLS Fallback SCSV:
Server supports TLS Fallback SCSV

  TLS renegotiation:
Session renegotiation not supported

  Heartbleed:
TLSv1.3 not vulnerable to heartbleed
TLSv1.2 not vulnerable to heartbleed

  Supported Server Cipher(s):
Preferred TLSv1.3  128 bits  TLS_AES_128_GCM_SHA256        Group X25519MLKEM768
Accepted  TLSv1.3  256 bits  TLS_AES_256_GCM_SHA384        Group X25519MLKEM768
Accepted  TLSv1.3  256 bits  TLS_CHACHA20_POLY1305_SHA256  Group X25519MLKEM768
Preferred TLSv1.2  256 bits  ECDHE-ECDSA-AES256-GCM-SHA384 Curve 25519 DHE 253
Accepted  TLSv1.2  256 bits  ECDHE-ECDSA-CHACHA20-POLY1305 Curve 25519 DHE 253
[... 11 more TLSv1.2 ECDHE-ECDSA suites, including CBC-mode AES-SHA and CAMELLIA ...]

  SSL Certificate:
Signature Algorithm: ecdsa-with-SHA384
ECC Curve Name:      prime256v1
Subject:  cybergym.hackergpt.app
Not valid before: Sep  8 18:41:13 2026 GMT
Not valid after:  Dec  7 18:41:12 2026 GMT

How to read it, line by line:

• Protocols. Only TLS 1.2 and TLS 1.3 are enabled, which is what RFC 8996 asks for. If your own scan shows TLSv1.0 enabled or TLSv1.1 enabled, that is the first thing to switch off.
• TLS Fallback SCSV. Supported, so a client and server cannot be pushed into a silent protocol downgrade (RFC 7507).
• Heartbleed. Not vulnerable. CVE-2014-0160 let an attacker read server memory through OpenSSL's heartbeat extension; it is rare today, but forgotten hosts still turn up.
• Ciphers. The server accepted 16 suites: 3 for TLS 1.3 and 13 for TLS 1.2 (the 2 listed plus the 11 elided). Every suite uses ECDHE key exchange, so all of them give forward secrecy. The TLS 1.2 list still accepts CBC-mode suites (AES256-SHA, AES128-SHA) next to the GCM and ChaCha20 ones. They are not broken, but a stricter configuration offers only AEAD suites; whether to drop them depends on how old the clients you must support are.
• Key exchange. TLS 1.3 prefers X25519MLKEM768, the hybrid post-quantum group described in the IETF draft draft-ietf-tls-ecdhe-mlkem.
• Certificate. Valid from 8 September to 7 December 2026. A 90-day certificate is fine as long as renewal is automated; an expiry date a few days away on your own scan is the finding that breaks a site soonest.

Counted from the sslscan output above: 3 TLS 1.3 suites, and 13 TLS 1.2 suites (the 2 shown plus the 11 elided).

A scan is a triage step. If something looks wrong, confirm it with a second tool or by connecting with openssl s_client before you change the server's configuration.

Is my site affected by a known CVE?

Look the CVE up in the public record, read its affected version ranges, and compare them with the exact versions your site runs; if your version is inside a range and the vulnerable component is actually used, you are likely affected and should patch. The version match alone is not proof: Linux distributions often backport fixes without changing the version string, so verify through the package manager or the vendor's advisory before reporting it.

Vulnerability Assessment

HackerGPT has three tools for this step:

The record cve_fetcher reads is the same one anyone can query. Here is the lookup for CVE-2026-111497, the Brotli decoder bug we cover in our HTTP2Shell brief, made against the NVD API on 24 October 2026 and trimmed to the fields that answer "am I affected?":

curl -s "https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2026-111497"

id:           CVE-2026-111497
published:    2026-10-22T14:17:37
lastModified: 2026-10-24T18:16:47
vulnStatus:   Awaiting Analysis
source:       cve-coordination@google.com (CNA)
weaknesses:   CWE-787 Out-of-bounds Write, CWE-252 Unchecked Return Value
cvssV4.0:     9.2 CRITICAL (Secondary, from the CNA)
              AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H
affected:     github.com/google/brotli
              1.0.3 <= version < 1.0.10
              1.1.0 <= version < 1.1.1
              1.2.0 <= version < 1.2.1

What the record tells you, and what it does not:

• The ranges are the answer. Brotli 1.0.3 to 1.2.0 is affected; 1.0.10, 1.1.1 and 1.2.1 are the fixed releases. If your app bundles Brotli through Node.js, a Python package or a proxy, the version to check is the bundled one, which the brief lists product by product.
• The score is the CNA's, not NVD's. vulnStatus: Awaiting Analysis means NVD has not scored it yet; the 9.2 under CVSS 4.0 comes from Google as the CVE numbering authority. Severity ratings can differ between sources, so note which one you are quoting.
• It does not say whether you are exposed. A record cannot know whether your code ever decodes untrusted Brotli data. That is the question to answer on your own system, with the checks in the brief.

The canonical record is also on cve.org. For other CVEs we have written up, see the PHP2Shell brief and the Vulnerabilities section.

WordPress Security Scanning (web_wpscan)

For a WordPress site, web_wpscan runs a CMS-specific scan: the core version, installed plugins and themes with their known vulnerabilities, and the user accounts the site reveals.

Scan the WordPress site at your-blog.example
Check for vulnerable plugins on your-blog.example
Enumerate users on your-blog.example

What requests does my web page make to its API?

Load the page in a real browser with network logging on and read the log: the XHR and fetch calls it records are the API endpoints the page uses, with their methods, headers and responses. A plain HTTP fetch of the same URL cannot show them, because in a single-page app those calls are made by JavaScript after the HTML arrives.

Browser Navigation & Network Logging

HackerGPT's browser loads pages, runs their JavaScript, clicks and fills forms, and records network traffic in the way the Network panel in Chrome DevTools does. Two tools drive it:

• navigation_engine_execute_instruction takes low-level commands (GO_TO_URL https://cybergym.hackergpt.app/, SCAN for the page content, WAIT 2, BACK) and plain-language instructions ("click the login button", "fill in the email field", "extract all links from the page").
• inspect_browser_session returns the browser's state: the current URL, the page title, a screenshot and the filtered network log.

Open browser at https://cybergym.hackergpt.app
Click the login button
What network requests were made?
Inspect the browser session

The difference this makes is easy to see. On 24 October 2026 we fetched CyberGym's home page twice, logged out: once with curl, once in a headless Chromium with network logging.

The same page fetched two ways on 24 October 2026. Only the browser, which runs the JavaScript, sees the API calls.

The curl fetch returned 75,294 bytes of HTML with no /rest/ or /api/ path in it. The browser made 42 requests, 17 of them XHR, including:

GET  https://cybergym.hackergpt.app/rest/admin/application-version (XHR) 200
GET  https://cybergym.hackergpt.app/rest/admin/application-configuration (XHR) 200
GET  https://cybergym.hackergpt.app/api/Challenges/?name=Score%20Board (XHR) 200
GET  https://cybergym.hackergpt.app/rest/languages (XHR) 200
GET  https://cybergym.hackergpt.app/api/Quantitys/ (XHR) 200
GET  https://cybergym.hackergpt.app/rest/products/search?q= (XHR) 200
POST https://cybergym.hackergpt.app/socket.io/?EIO=4&transport=polling&... (XHR) 200

Two of those calls sit under /rest/admin/ and answered 200 to a visitor who had not logged in. On CyberGym that is by design, since it is a practice target. On your own app, the same log is where to start asking which calls should have required a login, and which responses carry more than the page displays. Turning that log into a full inventory of endpoints with the auth each one requires is the subject of mapping a web app's attack surface, and it is what AppMap automates.

HTTP Requests (curl)

For a single request, curl fetches a URL and shows the response, headers included: reading robots.txt, checking which security headers a page sends, or replaying a request from the network log with one value changed.

Fetch the content of https://your-site.example/robots.txt
Check the response headers from your-site.example

Common Workflows

The tools are built to be chained in one conversation, each answer feeding the next prompt:

1. TLS audit: Perform SSL Scan on your-site.example and flag outdated protocols or ciphers.
2. From services to CVEs: Perform a service discovery scan and find associated CVEs on cybergym.hackergpt.app. The port and service side of this step is covered in the scanning and reconnaissance tools reference.
3. From a CVE to "am I affected?": Get details for CVE-2026-111497, then compare the affected ranges with what you run.
4. From a page to its API: Open browser at https://cybergym.hackergpt.app, then What network requests were made?.
5. WordPress: Scan the WordPress site at your-blog.example for vulnerable plugins.

Best Practices

• Get authorization first. Scan only systems you own or have written permission to test. CyberGym exists so you can practise without asking anyone.
• Treat findings as leads. A version match, a weak cipher or an unauthenticated endpoint is a finding to verify, not a verdict. Confirm with a second tool or by hand before you report or change anything.
• Watch for backports. Distribution packages often carry fixes without a new upstream version, so check the package changelog before calling a CVE confirmed.
• Re-scan after changes. TLS settings drift when servers, load balancers or CDNs are reconfigured; a scan after each change catches a protocol that came back.
• Keep WordPress current. Most WPScan findings point to outdated plugins and themes.

Key takeaways

• Check TLS with sslscan or an SSL scan prompt: TLS 1.2 and 1.3 only, AEAD ciphers where your clients allow it, and an expiry date renewed automatically.
• Answer "am I affected by this CVE?" from the record's affected version ranges, compared with the versions you actually run, and verify before you report.
• Note whose severity score you quote: a new CVE may carry only the CNA's score while NVD's analysis is pending.
• Use a browser with network logging, not a plain fetch, to see the API calls a single-page app makes; on CyberGym only the browser saw them.
• Start the review of that log with the calls that answered without a login.

Quick Reference

FAQ

How do I check which TLS versions my website supports?

Run sslscan your-site.example from any machine, or ask HackerGPT to perform an SSL scan on it. The "SSL/TLS Protocols" block lists each version as enabled or disabled. TLS 1.0 and 1.1 were deprecated by RFC 8996 in 2021, so only TLS 1.2 and 1.3 should show as enabled.

Does a CVE that matches my software version mean my site is vulnerable?

Not on its own. The version match tells you to look closer: your distribution may have backported the fix without changing the version, and the vulnerable code path may not be reachable in how you use the component. Confirm with the vendor's advisory or the package changelog, then patch.

Why does a CVE show a score from one source and "Awaiting Analysis" in NVD?

New CVEs are often scored first by the CVE numbering authority that published them, while NVD's own analysis follows later. The record then shows the CNA's score as "Secondary" and NVD's status as "Awaiting Analysis". Quote the score together with its source.

Why can't curl see the API calls my page makes?

curl downloads the HTML and does not run JavaScript. In a single-page app, the API calls are made by that JavaScript after the page loads, so only a browser that executes it, with network logging on, records them.

Can I try these tools without testing a real site?

Yes. CyberGym at cybergym.hackergpt.app is a deliberately vulnerable practice app you are allowed to scan, browse and test, and every example on this page was run against it.

Sources

• RFC 8996: Deprecating TLS 1.0 and TLS 1.1, IETF, March 2021
• RFC 8446: TLS 1.3, IETF, August 2018
• RFC 7507: TLS Fallback SCSV, IETF, April 2015
• draft-ietf-tls-ecdhe-mlkem: hybrid ECDHE-MLKEM key agreement for TLS 1.3, IETF
• sslscan, project repository
• CVE-2014-0160 (Heartbleed), NVD
• CVE-2026-111497, NVD, and the CVE record on cve.org
• NVD CVE API, NIST
• CVSS v4.0 specification, FIRST
• Network features reference, Chrome DevTools
• OWASP Juice Shop, OWASP