DEV Community: Gowri Shankar Balasubramaniam

Fixing MariaDB ERROR 2002 (HY000): TLS Handshake Fails with “Host Is Not Allowed to Connect”

Gowri Shankar Balasubramaniam — Fri, 23 Jan 2026 14:20:47 +0000

If you administer MariaDB in a secured environment, you may encounter the following confusing error while connecting from a remote host:

ERROR 2002 (HY000): Received error packet before completion of TLS handshake.
The authenticity of the following error cannot be verified:
1130 - Host '192.168.0.100' is not allowed to connect to this MariaDB server

At first glance, this looks like a TLS/SSL issue, but the root cause is often host-based access control, not encryption. This article explains why this happens, how TLS complicates the error message, and how to fix it securely.

Why This Error Is Misleading

The error appears during the TLS handshake phase, which causes MariaDB to suppress full reveal of server-side details. As a result:

MariaDB detects that the client host is not authorized
But TLS prevents full error verification
You receive a generic ERROR 2002 instead of a clean access-denied message

In short:

TLS is not broken authorization is.

Common Scenarios Where This Happens

This issue is frequently seen in environments with:

Enforced require_secure_transport=ON
TLS-enabled clients (--ssl / --ssl-mode=REQUIRED)
Remote application servers or containers
Hardened MariaDB installations (PCI DSS / SOC 2 aligned)

Typical causes include:

The client host IP is missing in mysql.user
The user exists only for localhost
Firewall or bind-address is not the issue (often misdiagnosed)

Step 1: Confirm the Server Is Reachable

From the client host (192.168.0.100):

nc -vz mariadb-server-ip 3306

If this succeeds, networking is not the problem.

Step 2: Inspect User Host Permissions (Critical Step)

sudo mariadb

Check allowed hosts for the user:

SELECT User, Host FROM mysql.user WHERE User = 'appuser';

Typical problematic output

+---------+-----------+
| User    | Host      |
+---------+-----------+
| appuser | localhost |
+---------+-----------+

This means remote connections are explicitly denied, regardless of TLS.

Step 3: Grant Access to the Correct Host

Option A: Allow a specific IP (recommended)

CREATE USER 'appuser'@'192.168.0.100'
IDENTIFIED BY 'StrongPassword'
REQUIRE SSL;

GRANT ALL PRIVILEGES ON appdb.* TO 'appuser'@'192.168.0.100';
FLUSH PRIVILEGES;

Option B: Allow a subnet (controlled environments)

CREATE USER 'appuser'@'192.168.0.%'
IDENTIFIED BY 'StrongPassword'
REQUIRE SSL;

⚠️ Avoid '%' unless strictly required.

⚠️ You may also use the local domain name instead of the IP address when creating the database user.

Step 4: Verify TLS Configuration

Check server TLS settings:

SHOW VARIABLES LIKE 'require_secure_transport';
SHOW VARIABLES LIKE 'ssl_%';

Expected secure configuration:

require_secure_transport = ON
ssl_ca   = /etc/mysql/ca.pem
ssl_cert = /etc/mysql/server-cert.pem
ssl_key  = /etc/mysql/server-key.pem

Step 5: Test Connection Explicitly with TLS

From the client:

mariadb \
  -h mariadb-server-ip \
  -u appuser \
  -p \
  --ssl-mode=REQUIRED

If the host permission is fixed, the TLS handshake will complete successfully.

Why MariaDB Throws ERROR 2002 Instead of ERROR 1130

Under non-TLS connections, you would normally see:

ERROR 1130 (HY000): Host 'x.x.x.x' is not allowed to connect

But when TLS is enforced:

The server aborts early
Detailed authentication errors are hidden
MariaDB returns ERROR 2002 as a generic failure

This is expected behavior in hardened setups.

Security Best Practices (Strongly Recommended)

✔ Use host-specific users, not %
✔ Enforce REQUIRE SSL
✔ Keep require_secure_transport=ON
✔ Rotate credentials after permission changes
✔ Log connection errors via log_error_verbosity=3

These align well with PCI DSS, SOC 2, and zero-trust principles.

Conclusion

This error is not a TLS failure, it is an access control failure masked by TLS.

Once the correct host-based user permission is added, the error disappears immediately.

CRITICAL RCE ALERT: Patch CVE-2025-61932 in LANSCOPE Endpoint Manager NOW! (Actively Exploited)

Gowri Shankar Balasubramaniam — Fri, 24 Oct 2025 08:09:49 +0000

I have found an urgent advisory regarding CVE-2025-61932, a critical Remote Code Execution (RCE) vulnerability discovered in LANSCOPE Endpoint Manager (On-Premises), developed by Motex Inc. (Japan). This advisory was published on October 20, 2025.

This is a live threat: the vulnerability has been added to CISA’s Known Exploited Vulnerabilities (KEV) Catalog, confirming that it is being actively exploited in the wild. Organizations globally must prioritize patching this issue immediately.

🚨 Technical Summary: Severe Risk and Impact

This vulnerability poses a grave risk, allowing remote attackers to achieve complete system compromise.

The core issue stems from Improper Verification of Source of a Communication Channel (CWE-940). An attacker can execute arbitrary code by sending specially crafted packets to a vulnerable endpoint.

Detail	Source Information
CVE Identifier	CVE-2025-61932
Affected Product	LANSCOPE Endpoint Manager (On-Premises)
Affected Components	Client (MR) and Detection Agent (DA) components
Exploit Vector	Remote, over TCP port 443 (HTTPS)
Criticality Score	CVSS v4.0 Score: 9.3 (Critical); CVSS v3.x Score: 9.8 (Critical)
Impact	Complete system compromise. Confidentiality, integrity, and availability are all at high risk. Attackers gain full control of endpoints.
Confirmed Exploitation	First observed exploited in the wild around April 2025. Exploitation may be used to drop an unspecified backdoor on compromised systems.

Global Relevance and Official Directives

While LANSCOPE is widely used in Japan and Asia for corporate IT governance, global exposure is confirmed, particularly among organizations in Europe (Germany, the Netherlands, and the U.K.) and North America.

Official agencies are treating this as an emergency:

CISA Mandate: The U.S. Cybersecurity and Infrastructure Security Agency (CISA) requires all U.S. federal agencies to remediate CVE-2025-61932 by November 12, 2025.
Regional Confirmation: The Japan CERT (JPCERT/CC) reported confirmed cases of receiving unauthorized packet traffic in domestic customer environments consistent with the exploit.

Compliance Risks (Especially for European Organizations)

For organizations in Europe, including Germany and the EU, this RCE capability presents a severe cybersecurity and compliance risk.

GDPR Violations: Unauthorized data access resulting from compromise could trigger GDPR violations, exposing companies to heavy penalties.
Operational Risk: System compromise can disrupt business operations and facilitate lateral movement to compromise domain controllers or confidential data stores.

✅ Immediate Action: Mitigation and Patching Steps

System administrators must prioritize rapid patching.

Step 1: Identify and Upgrade Affected Systems

The vulnerability affects all versions up to 9.4.7.1.

Immediately verify if LANSCOPE Endpoint Manager (On-Premises) is deployed and check the exact version numbers.

Upgrade all affected Client (MR) and Detection Agent (DA) components to one of the following patched versions or newer:

Fixed Version List
9.3.2.7
9.3.3.9
9.4.0.5
9.4.1.5
9.4.2.6
9.4.3.8
9.4.4.6
9.4.5.4
9.4.6.3
9.4.7.3 (or later)

(Note: While the Management Server component is reported as unaffected, it is recommended to patch it as a precaution).

Step 2: Restrict Network Access (If Immediate Patching is Delayed)

If LANSCOPE endpoints are accessible from external networks, take immediate temporary mitigation steps:

Limit access to trusted IPs or VPN users only.
Temporarily disable external connectivity on TCP 443 until the update is confirmed and applied.

Step 3: Monitoring, Validation, and Internal Communication

Monitor: Review server and endpoint logs for unusual activity. Look specifically for suspicious inbound connections or crafted HTTPS packets on port 443. Check for Indicators of Compromise (IoCs) shared by Motex or security vendors.
Validate: After applying updates, test system stability and verify that no endpoints remain exposed to public access.
Strengthen Security: Enforce strong authentication, least privilege configurations, endpoint firewalls, and continuous monitoring.
Communicate: Notify your IT Security and Compliance teams immediately and set a clear patch deadline, preferably before November 12, 2025.

About LANSCOPE Endpoint Manager

LANSCOPE Endpoint Manager is an enterprise endpoint management and security solution used to monitor, manage, and protect corporate devices. Developed by Motex Inc. (Japan), its key features include Asset Management, User Activity Monitoring, Patch & Policy Management, and Access Control & Device Auditing. It is vital for corporate IT governance, endpoint visibility, and data loss prevention.

Conclusion:

CVE-2025-61932 is a critical, actively exploited vulnerability. Proactive measures, strict access control, real-time monitoring, and rapid patching are essential to prevent remote compromise and reduce exposure worldwide.

5 Common Security Mistakes Developers Still Make (and How to Fix Them)

Gowri Shankar Balasubramaniam — Thu, 09 Oct 2025 15:34:58 +0000

Hey there, fellow developers! 👋

We all know security isn't just a "DevOps thing" or a "security team thing"—it's a core part of building good software. Yet, under tight deadlines or in the heat of a complex feature, it's easy to slip up. Based on what I've seen in projects big and small, there are a handful of security mistakes that just keep popping up.

Let's dive into five of the most common security blunders and, more importantly, lay out the practical, code-level fixes we can implement today using Node.js examples.

1. Trusting User Input (The Classic Blunder)

This one is ancient, but it never dies. Whether it's data from a web form, a URL parameter, or a JSON payload, all user input is hostile until proven otherwise. Failing to treat it as such is the fast track to vulnerabilities like SQL Injection or Cross-Site Scripting (XSS).

🛠️ The Fix: Parameterization and Sanitization

Use cases:
Mistake 1: SQL Injection - Directly concatenating user input into a database query string.

Solution: Use Parameterized Queries/Prepared Statements. When working with a database like PostgreSQL or MySQL in Node.js, libraries like pg or mysql2 support parameterized queries that separate the SQL logic from the data. An attacker's input is treated only as a value, not executable code.

Mistake 2: XSS: Displaying user-submitted text directly on a web page (e.g., a forum post).

Solution: Escape Output. Before rendering user data in the browser, always escape special characters (like <, >, &). Use template engines that auto-escape (like Handlebars or Pug) or dedicated libraries like dompurify if you must allow some HTML.

Sample Code:

// MISTAKE: SQL Injection Risk
// const user = 'admin\' OR \'1\'=\'1'; 
// connection.query(`SELECT * FROM users WHERE username = '${user}'`, (err, results) => { ... }); 

// FIX: Parameterized Query (The data is never mixed with the query structure)
const user = 'admin\' OR \'1\'=\'1'; 
const sql = 'SELECT * FROM users WHERE username = ?'; // Use a placeholder
connection.execute(sql, [user], (err, results) => { 
    // The malicious input is treated as a safe string value.
    if (err) throw err;
    console.log(results); 
});

This is the single most important rule of secure coding: Input Validation, Output Encoding.

2. Leaving Default/Insecure Configurations in Place

Every time you spin up a new service, a database, a cloud function, or a web framework (like Express) it comes with default settings. Often, these defaults are designed for ease of use or local development, not for production security. Things like default credentials, permissive firewall rules, or having debugging mode enabled fall into this category.

🛠️ The Fix: Principle of Least Privilege & Hardening

Change all Default Credentials: Use a secrets manager (like HashiCorp Vault or AWS Secrets Manager) and complex, unique credentials.
Disable Unnecessary Features: Turn off features you don't need. For Express apps, use the helmet middleware to set secure HTTP headers, which is a massive win for minimal effort.
Implement the Principle of Least Privilege (PoLP): Your Node.js process should only have the minimum permissions it needs to function. Don't run your application as the root user.

Code Example (Node.js with Express and Helmet):

// Protects your app from some well-known web vulnerabilities 
// by setting HTTP headers appropriately.
const express = require('express');
const helmet = require('helmet');
const app = express();

app.use(helmet()); 
app.get('/', (req, res) => {
    res.send('Hello Secure World!');
});

// A simple but critical step for web hardening!

3. Ignoring Dependency Vulnerabilities (The Supply Chain Risk)

We all rely on open-source packages, it's how modern development works. But every package you add (via npm install) is a potential entry point for an attacker.

You might be focused on writing secure application code, but if a third-party package you rely on has a critical vulnerability (a major issue with your node_modules!), your entire app is at risk.

🛠️ The Fix: Automation and Regular Audits

Use Software Composition Analysis (SCA) Tools: Utilize the built-in npm audit command. It automatically scans your package-lock.json against a public vulnerability database. Tools like Dependabot (for GitHub) or Snyk can also be integrated into your CI/CD pipeline.
Regular Updates: Make updating your dependencies a routine. Running npm audit fix regularly is much easier than scrambling when a major CVE (Common Vulnerabilities and Exposures) is announced.
Delete Unused Dependencies: If you're not using a library anymore, run npm uninstall . Less code, less risk.

Terminal Command Example:

# Run this command often!
npm audit 

# To automatically fix safe vulnerabilities
npm audit fix

4. Storing Secrets Directly in Code (The Git Blunder)

Storing API keys, database connection strings, or encryption keys directly in your source code is a critical mistake. It's often the first place an attacker looks after compromising a developer's machine or gaining access to a private repo.

🛠️ The Fix: Environment Variables and Dedicated Managers

Use Environment Variables: At a minimum, load secrets from environment variables using a library like dotenv. This keeps secrets out of the codebase by placing them in a .env file that is added to your .gitignore.
Adopt a Secrets Manager: For production, use a dedicated solution like AWS Secrets Manager, Azure Key Vault, or Kubernetes Secrets.
Pre-commit Hooks: Use tools like git-secrets to scan your code before it's committed to prevent accidentally pushing sensitive information.

Code Example (Node.js with dotenv):

// .env file (NEVER commit this to Git)
// DB_USER="my_secure_user"
// DB_PASS="long_random_password_123"

// server.js (loads secrets from .env or system environment)
require('dotenv').config();

const dbUser = process.env.DB_USER;
const dbPass = process.env.DB_PASS;

if (!dbUser || !dbPass) {
    throw new Error("Database credentials not found in environment variables!");
}

// Now safely use dbUser and dbPass for your connection logic...

5. Broken Authentication/Authorization (The "Who Can Do What" Problem)

These two are often confused:

Authentication: Who are you? (Logging in)
Authorization: What are you allowed to do? (Accessing resources)

A common mistake is forgetting to check authorization on every server-side API endpoint. For example, an attacker might log in as a standard user, then call a backend API endpoint that's only supposed to be accessible by an administrator. If the API doesn't have a check to see if the authenticated user has the "admin" role, you have a Broken Access Control vulnerability.

🛠️ The Fix: Deny-by-Default and Express Middleware

Deny-by-Default: Structure your authorization logic so that a user is denied access unless they are explicitly granted permission.
Use Server-Side Checks (Always!): Never rely solely on client-side (frontend) checks to hide or disable features. Your API must validate the user's rights for every resource request.
Implement Authorization Middleware: Use Express middleware to check roles before the main route handler executes.

Code Example (Node.js with Express Middleware):

// Middleware to check for the 'admin' role
const requireAdmin = (req, res, next) => {
    // Assume req.user object is populated after authentication 
    // CRITICAL SERVER-SIDE CHECK
    if (req.user && req.user.role === 'admin') {
        next(); // User is an admin, proceed to the route handler
    } else {
        // Stop the request immediately
        res.status(403).json({ message: 'Forbidden: Insufficient privileges' });
    }
};

// Apply the check to the sensitive route
app.delete('/api/users/:id', requireAdmin, (req, res) => {
    // This code only runs if the user is an admin
    // ... logic to delete user ...
    res.status(204).send();
});

Final Thoughts: Shift Left and Stay Curious

The best security practice is adopting a "Shift Left" mentality catching these issues as early as possible. Don't wait for a penetration test; build security into your code review process and daily habits.

Security is a constant learning process. What other security mistakes have you seen or fixed recently? Let me know in the comments! 👇