The security scan of 109.233.191.226 found 16 issues including 2 high-risk and 7 medium-risk findings. The most critical issue is 'SSL Certificate Hostname Mismatch' which requires immediate attention. Full remediation steps are provided for each finding below.
SSL certificate is for a different domain — visitors get a browser warning saying the site can't be trusted
This warning makes your business look unprofessional or compromised, and many visitors won't proceed past it — particularly damaging on login or checkout pages where trust matters most.
Example: A visitor reaches the site via a link that uses the 'www' version of the domain while the certificate only covers the bare domain (or vice versa) — triggering a browser warning that makes a legitimate business look fraudulent.
Get an SSL certificate that matches this exact domain name. Check: the cert may be for 'www.yourdomain.com' but you're visiting 'yourdomain.com' (or vice versa). Request a new cert that covers both versions, or use a wildcard cert (*.yourdomain.com). Let's Encrypt can issue this free: 'certbot --nginx -d yourdomain.com -d www.yourdomain.com'
CWE-297 — Improper Certificate Validation (Hostname Mismatch)
The system accepts a security certificate without checking that it actually matches the site being connected to.
The path /server-status returns a restricted-access response (401/403), and its content matches known indicators for this resource, confirming what it is — this exposes internal server diagnostic information, not a login panel
This page reveals internal details about the server's configuration, active connections, or recent errors — not something the general public should be able to see, and useful reconnaissance an attacker can use to plan a more targeted attack elsewhere on the site.
Example: An attacker reviews this page to learn internal server details, request patterns, or recent error messages, then uses that information to plan a more targeted attack elsewhere on the site instead of guessing blind.
Restrict access to /server-status by IP allowlist, or disable it entirely if not needed. Nginx: 'location ^~ /server-status { allow YOUR_IP; deny all; }'. Apache ('server-status'/'server-info'): add 'Require ip YOUR_IP' inside the relevant <Location> block, or remove the module if unused.
CWE-200 — Exposure of Sensitive Information
The system reveals information to someone who shouldn't have access to it.
Server accepts TLSv1.1 which is deprecated and insecure since 2020
Security scanners and compliance audits (PCI-DSS, SOC 2, cyber-insurance questionnaires, etc.) flag outdated TLS versions as a failing item, and major browsers are gradually moving toward blocking these connections entirely.
Example: A compliance auditor or cyber-insurance questionnaire runs an automated scan, flags the outdated TLS version as a failed control, and the business has to scramble to fix it before a policy renewal or contract can close.
Disable TLS 1.0 and 1.1 in your web server config. For Nginx: add 'ssl_protocols TLSv1.2 TLSv1.3;' to your server block. For Apache: set 'SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1' in ssl.conf. Then restart the server and verify at https://www.ssllabs.com/ssltest/
CWE-327 — Use of a Broken or Risky Cryptographic Algorithm
The encryption method in use is outdated or weak enough that attackers can break it with modern tools.
Visiting http:// doesn't redirect to https:// — some visitors may use an unencrypted connection without knowing
Anyone who types or clicks an http:// link is sending their activity on your site — potentially including form data or passwords — unencrypted, where it can be read by anyone on the same public wifi or compromised network.
Example: A customer types the domain into their browser without 'https://', lands on the unencrypted version of the site, and submits a form before ever reaching the secure page — sending that data in plain text the whole time.
Add a permanent redirect from HTTP to HTTPS. Nginx: add 'return 301 https://$host$request_uri;' in your port 80 server block. Apache: add 'RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]' in your .htaccess. Cloudflare users: go to SSL/TLS > Edge Certificates > enable 'Always Use HTTPS'.
CWE-319 — Cleartext Transmission of Sensitive Information
Sensitive data is sent over the network unencrypted, so anyone monitoring the connection can read it.
Missing Strict-Transport-Security (HSTS) — browsers aren't forced to always use HTTPS, leaving visitors open to downgrade attacks
An attacker on the same network as a visitor (public wifi, a compromised router, etc.) can trick their browser into using the insecure version of your site and intercept what they type — raising the odds of stolen logins or payment details.
Example: An attacker on a shared network intercepts a visitor's first request (which defaults to HTTP) before the redirect happens, and silently serves them a fake version of the page instead of the real site.
Add the HSTS header to your web server. Nginx: add 'add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;' in your server block. Apache: add 'Header always set Strict-Transport-Security "max-age=31536000"' in your config. Cloudflare: SSL/TLS > Edge Certificates > enable HTTP Strict Transport Security.
CWE-319 — Cleartext Transmission of Sensitive Information
Sensitive data is sent over the network unencrypted, so anyone monitoring the connection can read it.
Missing X-Frame-Options — your website can be embedded in an attacker's invisible iframe to trick users into unwanted actions
An attacker could trick your customers into clicking hidden buttons — like 'change password' or 'confirm purchase' — without realizing it, potentially leading to account takeovers or unauthorized actions carried out under your brand's name.
Example: An attacker embeds the site's 'delete account' or 'confirm payment' button inside an invisible iframe on their own page, disguised under something like a fake 'play video' button — a visitor's real click triggers the hidden action on your site.
Add the X-Frame-Options header. Nginx: 'add_header X-Frame-Options "SAMEORIGIN" always;' Apache: 'Header always set X-Frame-Options SAMEORIGIN' This tells browsers to only allow your site to be framed by pages on the same domain.
CWE-1021 — Improper Restriction of Rendered UI Layers (Clickjacking)
The site doesn't prevent itself from being embedded inside another page, which attackers can exploit to trick users into clicking something they didn't intend to.
Missing Content-Security-Policy (CSP) — this site has no CSP defense-in-depth layer, so if any cross-site scripting weakness exists elsewhere it's easier to exploit; this finding on its own doesn't mean an XSS vulnerability exists on this site
CSP is a defense-in-depth browser control, not evidence of an active vulnerability by itself — but if an attacker ever manages to slip malicious script onto your site through some other weakness (e.g. a vulnerable plugin or a comment field), a good CSP is often what stops that script from running and stealing customer data such as login sessions or payment details. Without it, that second layer of protection isn't there.
Example: A vulnerable comment form or compromised ad widget lets an attacker inject a script tag; with a properly scoped CSP in place, the browser would refuse to run it — without CSP, that same injected script runs freely and can forward a visitor's session cookie to the attacker.
Add a Content-Security-Policy header, but roll it out carefully — a misconfigured CSP can break legitimate scripts/styles on the site. Start by deploying it in Report-Only mode first, which reports violations without blocking anything: 'add_header Content-Security-Policy-Report-Only "default-src \'self\'; script-src \'self\'; object-src \'none\'; report-uri /csp-report";' Review the reports for a while to catch anything the policy would break, adjust the policy, then switch the header name to 'Content-Security-Policy' (without '-Report-Only') to start enforcing it. For WordPress or complex sites, use https://csp-evaluator.withgoogle.com to help build the policy.
CWE-693 — Protection Mechanism Failure
A security safeguard that should be protecting the system is missing, disabled, or not strong enough.
The path /phpmyadmin/ returns a restricted-access response (401/403) that is genuinely distinct from how this site handles random nonexistent paths — this confirms *something* is being specially handled at this path, but the response contains no content confirming what it actually is — this exposes administration functionality to anyone on the internet
Publicly reachable admin panels are a primary target for automated attacks. An attacker who can reach /phpmyadmin/ can attempt brute-force login, exploit known vulnerabilities in the admin software, or leverage it as a stepping stone to full server compromise — without needing any insider knowledge of the site.
Example: Automated bots constantly scan the internet for paths like /phpmyadmin/. A business that left a default admin URL accessible was compromised when a bot found it, brute-forced a weak password in minutes, and installed backdoor malware — all without any human attacker being involved.
Restrict access to /phpmyadmin/ by IP allowlist, move it to a non-standard path, or disable it if not needed. Nginx: 'location ^~ /phpmyadmin/ { allow YOUR_IP; deny all; }'. Also ensure strong, unique credentials are set for any admin accounts, and enable multi-factor authentication where supported.
The path /server-info returns a restricted-access response (401/403), and its content matches known indicators for this resource, confirming what it is — this exposes internal server diagnostic information, not a login panel
This page reveals internal details about the server's configuration, active connections, or recent errors — not something the general public should be able to see, and useful reconnaissance an attacker can use to plan a more targeted attack elsewhere on the site.
Example: An attacker reviews this page to learn internal server details, request patterns, or recent error messages, then uses that information to plan a more targeted attack elsewhere on the site instead of guessing blind.
Restrict access to /server-info by IP allowlist, or disable it entirely if not needed. Nginx: 'location ^~ /server-info { allow YOUR_IP; deny all; }'. Apache ('server-status'/'server-info'): add 'Require ip YOUR_IP' inside the relevant <Location> block, or remove the module if unused.
CWE-200 — Exposure of Sensitive Information
The system reveals information to someone who shouldn't have access to it.
Missing X-Content-Type-Options — browsers may guess file types incorrectly, which can enable content injection
This is a minor gap on its own, but it slightly raises the odds that a malicious file could be misread as something else by a visitor's browser, helping a separate attack succeed.
Example: A user-uploaded file intended to be harmless (like an image) is reinterpreted by the browser as executable script because the server never told it what the file actually was, letting an unrelated vulnerability turn into a working attack.
Add: 'add_header X-Content-Type-Options "nosniff" always;' (Nginx) or 'Header always set X-Content-Type-Options nosniff' (Apache). This is a one-line fix that takes 2 minutes.
CWE-693 — Protection Mechanism Failure
A security safeguard that should be protecting the system is missing, disabled, or not strong enough.
Missing Referrer-Policy — page URLs (which may include sensitive data) are shared with third-party sites your pages link to
If any of your page addresses contain sensitive details (like a password-reset token or account ID), that information could leak to outside sites your pages link to — a small but easily avoidable privacy gap.
Example: A customer clicks an outbound link from a page whose URL happens to include an account ID or a password-reset token, and that full address — token included — is handed to the destination site in the Referer header.
Add: 'add_header Referrer-Policy "strict-origin-when-cross-origin" always;' (Nginx) or 'Header always set Referrer-Policy strict-origin-when-cross-origin' (Apache).
CWE-16 — Configuration
The weakness comes from how the software was configured, not from a flaw in its code.
Missing Permissions-Policy — browser features like camera, microphone, and location aren't restricted for embedded third-party scripts
If you ever embed third-party ads, widgets, or analytics scripts, they could request a visitor's camera, microphone, or location without you intending to allow it — an avoidable privacy risk for your customers.
Example: An embedded ad network's script requests the visitor's location or microphone access through a permission prompt the site owner never intended to allow, simply because nothing in the page's headers restricted it.
Add: 'add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;' Adjust based on what your site actually uses. This limits what ad/analytics scripts can access.
CWE-693 — Protection Mechanism Failure
A security safeguard that should be protecting the system is missing, disabled, or not strong enough.
Server header reveals exact software version (Apache/2.4.41 (Win64) OpenSSL/1.1.1c PHP/7.3.12) — attackers search vulnerability databases for that version
Attackers use that exact version number to look up known, public vulnerabilities for that specific software release — making it easier to plan a targeted attack instead of guessing blind.
Example: An attacker searches a public vulnerability database for the exact server version shown in the response headers and finds a known, unpatched exploit for it — turning a blind guess into a targeted attack in seconds.
Hide the server version. Nginx: set 'server_tokens off;' in nginx.conf. Apache: set 'ServerSignature Off' and 'ServerTokens Prod' in apache2.conf. IIS: remove via IIS Manager > HTTP Response Headers, or use URLScan.
CWE-200 — Exposure of Sensitive Information
The system reveals information to someone who shouldn't have access to it.
Public IP 109.233.191.226 (hosted by Orion Telekom Tim d.o.o.Beograd) has no abuse reports on AbuseIPDB in the last 90 days.
A clean IP reputation is a good sign — no other indication needed here.
No action required.
Public IP 109.233.191.226 is registered to Orion Telekom Tim d.o.o.Beograd (RS) — network: RS-ORIONTELEKOMTIM-20091228 — block: 109.233.184.0 – 109.233.191.255.
This is informational — it tells you (and anyone else who looks it up) which hosting provider or network actually operates this IP. Useful for confirming you're hosted where you expect, or for context if the IP reputation check above flags anything.
No action required — this is identifying information, not a vulnerability.
Detected technology stack: Apache 2.4.41.
Knowing your exact software versions helps attackers pick targeted exploits instead of guessing — this isn't a vulnerability by itself, but it's worth knowing what your site publicly reveals about its own software.
No action required unless you'd prefer to hide version banners (e.g. removing WordPress's generator meta tag and readme.html, or disabling Apache/nginx's Server header version string) to make automated targeting slightly harder. Keeping the software itself patched matters far more than hiding the version number.
Your server is reachable, which means the web checks and SSL analysis were able to run successfully.