CVE Vulnerabilities

💬 Self Hosted Retool
1

Does Retool post a timeline for resolving security vulnerabiltiies? I ran a security scan on the latest image (3.196.20) at this time and there seems to be multiple that could be fixed quickly.

CPE vulnerabilities:

Name: cpe:2.3nodejs:node.js, Version: 20.18.1, Path: /usr/local/bin/node

  • CVE-2025-23083, Severity: HIGH, Source: Sign In to VulnCheck
    • CVSS score: 7.7, CVSS exploitability score: 2.5
    • Fixed version: 20.18.2
  • CVE-2025-23166, Severity: HIGH, Source: Sign In to VulnCheck
    • CVSS score: 7.5, CVSS exploitability score: 3.9
    • Fixed version: 20.19.2

Library vulnerabilities:

Name: com.databricks:databricks-jdbc, Version: 2.6.32, Path: /retool_backend/jdbcdrivers/DatabricksJDBC42.jar

Name: com.fasterxml.jackson.core:jackson-core, Version: 2.13.4, Path: /retool_backend/jdbcdrivers/DatabricksJDBC42.jar -> META-INF/maven/com.fasterxml.jackson.core/jackson-core

Name: axios, Version: 0.27.2, Path: /retool_backend/package.json

Name: form-data, Version: 4.0.3, Path: /retool_backend/package.json

Name: jspdf, Version: 2.5.1, Path: /retool_backend/package.json

Name: knex, Version: 0.21.16, Path: /retool_backend/package.json

Name: mysql2, Version: 2.3.3, Path: /retool_backend/package.json

Summary:

  • Vulnerable packages: CRITICAL: 2, HIGH: 6, MEDIUM: 0, LOW: 0, INFORMATIONAL: 0
    Total: 8
  • Vulnerabilities: CRITICAL: 3, HIGH: 8, MEDIUM: 0, LOW: 0, INFORMATIONAL: 0
    Total: 11 (all fixable)
3

heh, I always find CVEs interesting. I can't help but wonder what these people were doing to find these problems. I do not work for Retool. I'll safely start there lol. I've been going over these CVEs that you linked and from what I can tell they COULD potentially implement fixes for these, but I do have to wonder if those "fixes" might actually break other users code. like implementing a fix for the mysql2 library might work as long as the backend uses it, but what happens when someone imports the library? well, now we have a situation where for some people the db connection works and others it doesn't, creating a dev nightmare (how do yo find a problem that only exists under rare circumstantces? not easily, that's for sure). There is the other side this however... they very well COULD have implemented fixes however their config file states the library version originally installed and won't consider any changes they've made locally. So scans of the client downloaded js would still report vulnerable libraries as a false positive.

Outside of that, we can look at these individually and you'll notice they seem to be split between 2 possible attack vectors:

  • an angry developer out for their revenge for whatever
  • malicious intent from unknown 3rd party (or end user, doesn't matter we see them the same on the server side)

thankfully, Retool devs have considered this and we have implemented authorization and access control policies. There isn't much else they can do to help protect you from internal "problems" other than push for security requirements (good luck, we can hope, but "don't underestimate stupid people in stupid numbers" is always my favorite saying.). So we can ignore those CVEs as they don't apply (the security measures implemented by Retool prevent these CVEs from being possible).

The rest of the CVEs seem to have to do with either the REST request body or the URL iteself. Ignoring possible insider problems w the request body (we've "solved" that, no need to beat a dead horse eh?), these issues have to do with connecting to an unknown source.... so you provide the code to connect to a MYSQL db but your users supply the connection string. Some of these CVEs can only be achieved with certain request body types, like providing a URL in the user_id field, these types of issues would be absolutely amazing if they could be prevented on the backend, unfortunately tho this isn't the problem of the backend, it's a problem with implementing the use of the backend (aka the front... i'm not pointing fingers, i need you UI/UX people so I don't have to stare at command lines 24/7).... which comes down to the coder. The coder in this case comes down to either you, when you implement custom code/components, or a Retool dev giving us a new component (trust here is gained by you paying for a service). Now some backend devs may not handle improperly formatted parameters being sent to them (as is the case with a lot of internal APIs, if you know 100% where the data comes from then force them to send whats correct don't let them force you to ensure they send what's proper, there's no need to punish every other user of the backend just to ensure all parameters are correct), but your "backend people" are Retool and they do understand this problem which is what Retool really is.... a 'normie-friendly' platform built on-top of a 'nerd-friendly' platform

TLDR; while these CVEs might be a problem, they're assuming basic/lazy implementation of their referenced resource/library which Retool has not done, they've gone above and beyond the expected (proof is with custom auth pipelines imo)

edit: i can't help myself, the 'nerd-friendly' platform is built on-top of the 'turbo-nerd-friendly' platform.... c/c++ :joy:, I'd keep going, but nobody ever wants to anger the only guy, and masochist (again, no offense), at any company that understands assembly :rofl:

1 Like
4

Thanks for chimning in, @bobthebear! :grinning:

@tdicken73 I see this was also discussed internally, so I'm sharing the internal response for visibility here -

  1. cpe:2.3nodejs:node.js, Version: 20.18.1, Path: /usr/local/bin/node
    This vulnerability is not reachable within Retool source code

  2. com.databricks:databricks-jdbc, Version: 2.6.32, Path: /retool_backend/jdbcdrivers/DatabricksJDBC42.jar
    This vulnerability is not reachable within Retool source code but this library is being updated to a fixed version in our next Q3 stable release scheduled for Sept 9th

  3. com.fasterxml.jackson.core:jackson-core, Version: 2.13.4, Path: /retool_backend/jdbcdrivers/DatabricksJDBC42.jar -> META-INF/maven/com.fasterxml.jackson.core/jackson-core
    This vulnerability is not reachable within Retool source code but this library is being updated to a fixed version in our next Q3 stable release scheduled for Sept 9th

  4. axios, Version: 0.27.2, Path: /retool_backend/package.json
    This vulnerability is not reachable within Retool source code but this library is being updated to a fixed version in our next Q3 stable release scheduled for Sept 9th

  5. form-data, Version: 4.0.3, Path: /retool_backend/package.json
    This vulnerability has low impact on how it's used within Retool source code but this library is being updated to a fixed version in our next Q3 stable release scheduled for Sept 9th

  6. jspdf, Version: 2.5.1, Path: /retool_backend/package.json
    This vulnerability has low impact on how it's used within Retool source code but this library is being updated to a fixed version in our next Q3 stable release scheduled for Sept 9th

  7. knex, Version: 0.21.16, Path: /retool_backend/package.json
    This vulnerability is not reachable within Retool source code

  8. mysql2, Version: 2.3.3, Path: /retool_backend/package.json
    This vulnerability is not reachable within Retool source code but this library is being updated to a fixed version in our next Q3 stable release scheduled for Sept 9th

1 Like