SQL Injection in Netmaker SQLite Database Backend
Summary
The sqliteDeleteRecord function in Netmaker's database layer constructs SQL DELETE statements using direct string concatenation of user-supplied input. This allows an authenticated attacker to perform boolean-based SQL injection.
---
Details
The endpoint:
DELETE /api/dns/{network}/{domain}
passes user-controlled path parameters through the following flow:
logic.DeleteDNS → database.DeleteRecord → sqliteDeleteRecord
Depending on the configured database backend, the request eventually reaches the SQLite database implementation.
Vulnerable Code
The SQL query is constructed using direct string concatenation without parameterization.
go // database/sqlite.go deleteSQL := "DELETE FROM " + tableName + " WHERE key = \"" + key + "\""
The key value originates from user input ({domain} path parameter) and is embedded directly into the SQL query.
Exploitation
An authenticated attacker can inject SQL operators into the {domain} path parameter to manipulate the query logic.
Because this injection is boolean-based, attackers extract data indirectly by observing the outcome of the operation:
If the injected condition evaluates true, the DNS record is deleted.
If the condition evaluates false, the DNS record remains.
By repeating this process, an attacker can infer information such as:
Database table names
Column names
Column values
Value lengths
Impact
An authenticated attacker can exploit this vulnerability to extract data from arbitrary database tables when using the SQLite backend.
Unaffected backend:
PostgreSQL (uses parameterised queries with $1, $2 placeholders)
Patches
This vulnerability is fixed in version (fill in).
The patch replaces string concatenation with parameterised SQL queries for all user-supplied values in database operations.
--- Credit
Artem Danilov (Positive Technologies)
Daniil Satyaev (Independent)
Netmaker makes networks with WireGuard. Prior to version 1.2.0, the /api/server/shutdown endpoint allows termination of the Netmaker server process via syscall.SIGINT. This allows any user to repeatedly shut down the server, causing cyclic denial of service with approximately 3-second restart intervals. This issue has been patched in version 1.2.0.
Netmaker is a platform for creating and managing virtual overlay networks using WireGuard. Prior to versions 0.8.5, 0.9.4, and 010.0, there is a hard-coded cryptographic key in the code base which can be exploited to run admin commands on a remote server if the exploiter know the address and username of the admin. This effects the server (netmaker) component, and not clients. This has been patched in Netmaker v0.8.5, v0.9.4, and v0.10.0. There are currently no known workarounds.
Use of Hard-coded Cryptographic Key in Go github.com/gravitl/netmaker prior to 0.8.5,0.9.4,0.10.0,0.10.1.
Netmaker makes networks with WireGuard. Prior to version 0.15.1, Improper Authorization functions lead to non-privileged users running privileged API calls. If someone adds users to the Netmaker platform who do not have admin privileges, they can use their auth tokens to run admin-level functions via the API. This problem has been patched in v0.15.1.
Impact A Mass assignment vulnerability was found allowing a non-admin user to escalate privileges to admin user.
Patches Issue is patched in 0.17.1, and fixed in 0.18.6+.
If Users are using 0.17.1, they should run "docker pull gravitl/netmaker:v0.17.1" and "docker-compose up -d". This will switch them to the patched users
If users are using v0.18.0-0.18.5, they should upgrade to v0.18.6 or later.
Workarounds If using 0.17.1, can just pull the latest docker image of backend and restart server.
References Credit to Project Discovery, and in particular https://github.com/rootxharsh , https://github.com/iamnoooob, and https://github.com/projectdiscovery
Impact An IDOR vulnerability was found in the user update function. By specifying another user's username it is possible to update the other user's password.
Patches Issue is patched in 0.17.1, and fixed in 0.18.6+.
If Users are using 0.17.1, they should run "docker pull gravitl/netmaker:v0.17.1" and "docker-compose up -d". This will switch them to the patched users
If users are using v0.18.0-0.18.5, they should upgrade to v0.18.6 or later.
Workarounds If using 0.17.1, can just pull the latest docker image of backend and restart server.
References Credit to Project Discovery, and in particular https://github.com/rootxharsh , https://github.com/iamnoooob, and https://github.com/projectdiscovery
Impact Hardcoded DNS key usage has been found in Netmaker allowing unauth users to interact with DNS API endpoints.
Patches Issue is patched in 0.17.1, and fixed in 0.18.6+.
If Users are using 0.17.1, they should run "docker pull gravitl/netmaker:v0.17.1" and "docker-compose up -d". This will switch them to the patched users
If users are using v0.18.0-0.18.5, they should upgrade to v0.18.6 or later.
Workarounds If using 0.17.1, can just pull the latest docker image of backend and restart server.
References Credit to Project Discovery, and in particular https://github.com/rootxharsh , https://github.com/iamnoooob, and https://github.com/projectdiscovery
Authentication Bypass vulnerability exists in Netmaker versions prior to 1.5.0. The VerifyHostToken function in logic/jwts.go fails to validate the JWT signature when verifying host tokens. An attacker can forge a JWT signed with any arbitrary key and use it to impersonate any host in the network, gaining access to sensitive information
Netmaker makes networks with WireGuard. Prior to version 1.5.0, the user update handler (PUT /api/users/{username}) lacks validation to prevent an admin-role user from assigning the super-admin role during account updates. While the code correctly blocks an admin from assigning the admin role to another user, it does not include an equivalent check for the super-admin role. This issue has been patched in version 1.5.0.
A user assigned the platform-user role can retrieve WireGuard private keys of all wireguard configs in a network by calling GET /api/extclients/{network} or GET /api/nodes/{network}. While the Netmaker UI restricts visibility, the API endpoints return full records, including private keys, without filtering based on the requesting user's ownership.