I've come back to share knowledge again after being in a long hiatus. Though it's more of a "back to the job searching" situation at the moment. I've recently been looking over recent CVEs and thought I'd share some knowledge of a rather common source of vulnerabilities: string interpolation.
What Is String Interpolation?
This is a common feature of most programming languages which is a string containing special values which are then interpreted by the appropriate runtime. Here's a simple example in python:
input_string = "Hello, World"
print(f"Variable expanded to: {input_string}")
This would output Variable expanded to: Hello, World when run (well unless you're running a fairly old version of python). These are referred to as formatted string literals or f-strings. In this case the {input_string} is a placeholder which is taken by the python runtime and expanded out to the "Hello, World" string. Now a more practical use of this is taking user content and interacting with systems in a dynamic way. Unfortunately, not every user has good intentions.
String Interpolation Security
Given how widely used string interpolation is there's several categories of them you can find. The differences tend to be what the overall impact of a successful exploitation is. In most cases these exploits can be prevented by using context specific functions to cleanup any potential malicious content.
The Infamous eval
eval in many languages is a function that will evaluate the contents of a string (though certain languages may accept other objects). The main security issue with it is there's no real context and it's unrestricted for the most part. Some languages may offer a more filtered version of eval such as python's ast.literal_eval(). In general though it's best to avoid eval and use context specific methods for dealing with user input data.
CVE-2025-48868 is an example of eval being used insecurely.
Shell Parsing
This is a specific security concern for programs which deal with running commands based on dynamic user input variables. An example would be an app that uses ffmpeg to produce thumbnails or re-encode videos. Many of these issue arise if the command is run in a shell environment such as /bin/bash which supports several programming language primitives. In python for example popen can accept a shell=True argument to run it as such.
This can bit tricky to protect against depending on context. It is possible to spawn the command as a simple process to avoid dealing with certain shell primitives being replaced or acting with unintended consequences. That said, you also have to consider if running programs where the arguments are commands to run. Examples of this are sh -c and python -c. You can also associate the process with unprivileged users for most process related functions as well as run the process in a restricted environment.
CVE-2026-40030 is a good example of this being exploited.
Cross Site Scripting (XSS)
This is exploiting string interpolation of the browser. What happens is you have a part of a website, such as a forum post, where users are able to submit their own content. Without any kind of filtering, a user could inject malicious javascript which could redirect a victim to a malware site or view information on the page. Mozilla's developer site has a security article on defending against these sort of attacks which I recommend looking into.
CVE-2024-29184 is an example of an XSS exploit that even shows how you can bypass one of the defenses against it.
SQL Injection
This is a specific exploit against how databases parse queries. It's common enough that there's even an xkcd comic on the topic. This relies on closing out the intended SQL statement early, adding a malicious statement, and then using a comment to ignore the rest and prevent errors from bailing out the call. As an example from the comic:
Robert'); DROP TABLE Students;--
The Robert'); is assuming the query looks something like this:
SELECT email FROM Students WHERE name='$name_here');
So in this case you would get:
SELECT email FROM Students WHERE name='Robert'); DROP TABLE Students;--');
Which effectively turns it into a multi statement query which drops the table entirely. the -- is a comment which tells the SQL parser to ignore the rest of the string. While there are other methods of defense prepared statements with parameterized queries is a popular method of defense. That's because the SQL itself and the input variables are separated out.
CVE-2025-1094 is an example of a SQL injection, though targeting a CLI tool instead of the standard web app exploits you would generally find.
Path Traversal
This is a security issue where code reading string provided directory paths don't filter or restrict properly leaving the ability to access files that aren't intended. Let's say that there's an API endpoint that lets you download a file. In the request you put ../../../etc/passwd. A server which doesn't filter paths would deliver the /etc/passwd file to the user assuming the relative path lead to it. Obtaining the proper amount of directory traversal can be trial and error, though the accuracy can be improved by other means such as information leakage.
Many programming languages work to avoid this by having specific functions which set a path anchor and anything above that will fail. pathlib.PurePath.relative_to in python is also an example of this. Some 3rd party firewalls such as AWS WAF can sometimes have rules to block such attacks.
CVE-2025-68428 is an example of exploiting path traversal.
Wrap Up
If there's one major point to get out of this I would say that in general it's best to not trust user input data. You want to ensure that your risk mitigations assume a malicious actor could abuse user input to attempt an exploit. When you see a string based on user input, consider if there are methods in the language of choice which have context around how you wish to utilize the user data in question. You also want to make sure to have defense in depth. So putting a web application firewall in front of your web servers can help avoid disaster if insecure code manages to slip through. You will want to keep track of what it blocked and insure you're protecting against it on the code side however.
Top comments (0)