Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
12 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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…
Recommended action: Upgrade to 1.5.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Netmaker by Gravitl is an open-source WireGuard-based networking platform for creating and managing virtual overlay networks. The VerifyHostToken function in logic/jwts.go does not validate the JWT signature when verifying host tokens. After calling jwt.ParseWithClaims, the function only checks whether the returned token object is non-nil. It does not check token.Valid or the returned error. An attacker can forge a JWT signed with any key, set the claims to any host ID, and pull that host's full configuration including bcrypt-hashed passwords, MQTT credentials, and WireGuard peer data. The issue was patched in v1.5.0.
Recommended action: Upgrade to 1.5.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Credits Artem Danilov (Positive Technologies)
Recommended action: Upgrade to 1.5.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Credits Artem Danilov (Positive Technologies)
Recommended action: Upgrade to 1.5.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Authorise middleware in Netmaker incorrectly validates host JWT tokens. When a route permits host authentication (hostAllowed=true), a valid host token bypasses all subsequent authorisation checks without verifying that the host is authorised to access the specific requested resource. Any entity possessing knowledge of object identifiers (node IDs, host IDs) can craft a request with an arbitrary valid host token to access, modify, or delete resources belonging to other hosts. Affected endpoints include node info retrieval, host deletion, MQTT signal transmission, fallback host updates, and failover operations. Credits Artem Danilov (Positive Technologies)
Recommended action: Upgrade to 1.5.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 1.2.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/gravitl/netmaker < 0.17.1; >= 0.18.0, < 0.18.6
Fixed in
0.17.10.18.6· Vendor fix available
Issue
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
Recommended action: Upgrade to 0.18.6 or 0.17.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/gravitl/netmaker < 0.17.1; >= 0.18.0, < 0.18.6
Fixed in
0.17.10.18.6· Vendor fix available
Issue
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
Recommended action: Upgrade to 0.18.6 or 0.17.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/gravitl/netmaker < 0.17.1; >= 0.18.0, < 0.18.6
Fixed in
0.17.10.18.6· Vendor fix available
Issue
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
Recommended action: Upgrade to 0.18.6 or 0.17.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Improper Authorization functions leads to non-privileged users running privileged API calls. If you have added users to your Netmaker platform who whould not have admin privileges, they could use their auth token to run admin-level functions via the API. In addition, differing response codes based on function calls allowed non-users to potentially brute force the determination of names of networks on the system. Patches This problem has been patched in v0.15.1. To apply: 1. docker-compose down 2. docker pull gravitl/netmaker:v0.15.1 3. docker-compose up -d For more information If you have any questions or comments about this advisory: Email us at info@netmaker.io This vulnerability was brought to our attention by @tweidinger
Recommended action: Upgrade to 0.15.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/gravitl/netmaker < 0.8.5; >= 0.9.0, < 0.9.4
Fixed in
0.8.50.9.4· Vendor fix available
Issue
Impact There is a hard-coded cryptographic key in the code base which can be exploited to run admin commands on a remote server, if you know the address and username of the admin. This effects the server (netmaker) component, and not clients. Patches This has been patched in Netmaker v0.8.5, v0.9.4, and v0.10.0. If you are running these versions, the fix is to perform the following: 1. docker-compose down 2. docker pull gravitl/netmaker:( version ) 3. docker-compose up -d Additional Information If you are running any other version, you will need to upgrade to one of these three versions. If you have a special circumstance that requires running a different version, let us know and we may be able to build a custom patch. For more information If you have any questions or comments about this advisory: Email us at info@gravitl.com
Recommended action: Upgrade to 0.9.4 or 0.8.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/gravitl/netmaker < 0.8.5; >= 0.9.0, < 0.9.4
Fixed in
0.8.50.9.4· Vendor fix available
Issue
Netmaker prior to versions 0.8.5, 0.9.4, 0.10.0, and 0.10.1 uses a hard-coded cryptographic key.
Recommended action: Upgrade to 0.9.4 or 0.8.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.