We Found 13 Vulnerabilities on a Cybersecurity Firm's Website

Summary: We examined a cybersecurity firm’s website using entirely passive methods. We found 13 vulnerabilities — open directory listing, exposed admin account, zero security headers. A firm claiming to offer penetration testing services can’t pass a basic security check on its own website. We ran the same tests on our site: 0 vulnerabilities.

---

When you open a cybersecurity firm’s website, what do you expect?

Solid infrastructure. Current technology. Fundamental security standards applied without exception. At the very least, their own door should be locked.

That’s what we expected too.

We examined a firm operating in the sector during a routine scan. Our method was entirely passive — no login attempts, no attacks, no exploits. Just publicly accessible information. A browser and a few command-line queries.

The results surprised us.

---

Method: Passive Reconnaissance (OSINT)

Our test used the following tools:

• HTTP header analysis — Response headers via curl -I
• DNS queries — Record verification via dig
• WordPress REST API — Publicly accessible endpoints
• SSL certificate check — openssl s_client
• Directory access control — Direct URL visits

At no point did we perform any action that could harm, overload, or gain unauthorized access to the target system. All data was obtainable by any internet user with a browser.

---

Findings: 13 Vulnerabilities

1. Open Directory Listing — High

The server directly lists directory contents. Anyone visiting /wp-content/uploads/ can see all uploaded files.

Not just uploads — the plugin directory, theme directory, and subdirectories are all browsable.

OWASP: A01:2021 — Broken Access Control

A cybersecurity firm with open directory listing on its server is like leaving the front door wide open while selling home security systems.

---

2. User Enumeration (REST API) — High

User information is fully exposed through the WordPress REST API:

GET /wp-json/wp/v2/users

This single request returns:

• Username: admin
• User ID: 1
• Profile URL
• Gravatar hash value

The attacker now knows exactly who to target.

---

3. Default Admin Username — High

The administrator account uses the default admin username — the very first thing that should be changed in any WordPress installation.

Automated brute-force tools (WPScan, Hydra) try admin first. Half the attacker’s work is already done.

A firm that claims to perform penetration testing uses the default username on its own admin account. Let that sink in for a moment.

---

4. Plugin Information Disclosure — High

Plugin readme.txt files are directly accessible, revealing plugin names, versions, and supported WordPress versions.

Plugin	Version	Tested Up To
LoftLoader	2.5.1	6.6
Page Scroll to ID	1.7.9	6.8

This information is sufficient for targeted CVE database searches.

OWASP: A05:2021 — Security Misconfiguration

---

5. WordPress Version Exposed — Medium

The WordPress version is readable from three separate points:

1. HTML meta tag: <meta name="generator" content="WordPress 6.9.4">
2. RSS feed: <generator>...?v=6.9.4</generator>
3. Static file parameters: ver=6.9.4

Additionally: Site Kit by Google 1.175.0 is visible in meta tags.

Handing the attacker a technology map makes targeted exploitation trivial.

---

6. Security Headers: 0/7 — Medium

None of the critical security headers exist in the HTTP response:

Header	Status	Threat Mitigated
Content-Security-Policy	MISSING	XSS, data injection
Strict-Transport-Security	MISSING	SSL downgrade
X-Frame-Options	MISSING	Clickjacking
X-Content-Type-Options	MISSING	MIME-type sniffing
Referrer-Policy	MISSING	Information leakage
Permissions-Policy	MISSING	Browser API abuse
X-XSS-Protection	MISSING	Legacy browser XSS

0 out of 7 present.

Interestingly, wp-login.php has X-Frame-Options and CSP. Someone made a half-hearted configuration attempt but forgot to apply it to the pages the public actually sees.

---

7. Login Page Exposed — Medium

wp-login.php is accessible without any restrictions:

• No rate limiting
• No CAPTCHA
• No IP restriction
• Two-factor authentication could not be verified

The username is already known (findings #2 and #3). All that remains is guessing the password.

---

8. Gravatar Hash Exposure — Medium

The admin user’s Gravatar hash is plainly visible in the REST API response. This hash is a SHA-256 digest of the email address.

Rainbow table services or hash lookup tools can recover the email address. Once obtained: phishing, social engineering, and password reset attacks become possible.

---

9. Cookie Security Deficiency — Medium

The wordpress_test_cookie lacks the SameSite attribute. While Secure and HttpOnly flags are present, SameSite=Strict or Lax is missing — leaving a gap in CSRF protection.

---

10. SSL Certificate Configuration — Low

• Provider: Google Trust Services (free)
• Validity: 90 days (auto-renewal)
• Type: DV (Domain Validation) — lowest verification level

An OV or EV certificate is expected from a cybersecurity firm. A free DV certificate sends the weakest possible trust signal.

---

11. Version Leakage (CSS/JS) — Low

Version parameters exposed in static files:

Source	Version
WordPress Core	6.9.4
Astra Theme	4.11.1
Page Scroll to ID	1.7.9
Site Kit by Google	1.175.0

Each version number is a search key in CVE databases.

---

12. Autoindex Module Active — Low

The origin server’s autoindex module is enabled. Despite being behind Cloudflare, directory requests return file listings — a fundamental web server misconfiguration.

---

13. SEO Plugin Disclosure — Low

The sitemap XML file contains a comment revealing the plugin:

<!-- XML Sitemap generated by Rank Math SEO Plugin -->

Low risk alone. But combined with other findings, it completes the attacker’s technology map.

---

Comparison: We Ran the Same Test on Ourselves

Claims are easy. Proof is hard. We applied the same passive reconnaissance to our own infrastructure:

Criterion	Examined Firm	SiberKale
Security headers	0/7	7/7
User exposure	admin exposed	None (static site)
Directory listing	Open	Blocked (403/404)
CMS type	WordPress (dynamic)	Astro (static — zero attack surface)
SPF policy	Unknown	-all (hardfail)
DMARC policy	Unknown	reject
DKIM	Unknown	RSA 2048-bit
SSL	DV (free)	Let’s Encrypt + HSTS preload

The difference speaks for itself.

---

Why This Matters

According to Verizon’s 2024 DBIR, 68% of data breaches stem from human error or misconfiguration. Every single finding in this article is a configuration error.

A cybersecurity firm should know these mistakes. Should detect them. And should have fixed them on its own systems first.

A firm that can’t protect its own castle can’t protect yours.

---

Checklist: Before Choosing a Cybersecurity Firm

Before engaging any firm, run these checks:

1. Scan the firm’s website with securityheaders.com. Anything below A or B is a warning sign.
2. Try /wp-json/wp/v2/users. If it returns user data, basic hardening hasn’t been done.
3. Check the SSL certificate type. DV isn’t enough — expect OV or EV.
4. Query SPF, DKIM, and DMARC records. MX Toolbox gives results in 30 seconds.
5. Test directory access. If /wp-content/uploads/ is open, server configuration has been neglected.

A firm that fails every one of these checks cannot credibly claim to protect your systems.

---

Conclusion

This article is not an attack — it’s an observation. All data was obtained from publicly available sources. No unauthorized access was attempted.

Our goal is simple: to help organizations make informed decisions when choosing cybersecurity services. The easiest way to judge whether a firm can protect you is to check how well it protects itself.

A website harboring 13 vulnerabilities says a great deal about technical competence.

If you take cybersecurity seriously — vet the firm first. Then choose.

---

Want to know your own website’s security status? Get in touch — we offer free preliminary assessments.