Skip to content

Add files via upload #6

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
iben20 wants to merge 1 commit into from
Closed

Add files via upload #6

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
55 changes: 55 additions & 0 deletions VulnerablePythonScript.py
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,55 @@
import os
import subprocess
import requests
from flask import Flask, request

app = Flask(__name__)

# Vulnerability 1: Insecure Use of Subprocess (Command Injection)
@app.route('/ping', methods=['GET'])
def ping():
ip = request.args.get('ip', '')
result = subprocess.check_output(['ping', '-c', '4', ip])
return result

# Vulnerability 2: Hardcoded Credentials
USERNAME = 'admin'
PASSWORD = 'password123'

@app.route('/login', methods=['POST'])
def login():
username = request.form['username']
password = request.form['password']
if username == USERNAME and password == PASSWORD:
return "Login successful"
else:
return "Login failed", 401

# Vulnerability 3: Insecure Deserialization
@app.route('/unserialize', methods=['POST'])
def unserialize():
import pickle
data = request.data
obj = pickle.loads(data)

@github-actions github-actions Bot Mar 18, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Auto-generated PR comment (Polaris)

Polaris SAST Issue - Insecure Object Deserialization

High CWE-502
A user-controllable string is deserialized.

An attacker can instantiate arbitrary classes, possibly resulting in a denial of service or potentially unintended code execution.

How to fix

The application should avoid using object deserialization for data shared outside a trusted system.

The following things should be taken into consideration for remediation of this issue:

  • Sensitive data should never be included without in serialized state that is sent to a client. If sensitive data is included in serialized state, it must be encrypted with a key that is only available to authorized entities for decrypting the sensitive data.
  • Serialized data must be protected from unauthorized modification, i.e., it should use some form of integrity protection such as a keyed MAC or being digitally signed.
  • Data entering via an untrusted source (e.g., client) should never be deserialized. If this is not possible, then the application must explicitly specify and enforce which classes that should be allowed to be deserialized. It is important to note that it is not sufficient to add validation checks within the class that the application expects to deserialize, as an attacker can create a serialized object of any class they choose, which would then bypass such validation. It is important to strictly control which classes are allowed to be deserialized.

If using Java, it is recommended to use a run-time "agent" such as notsoserial (https://github.com/kantega/notsoserial) to specify and control which classes that should be allowed to be deserialized. Furthermore, it is strongly recommended to use the latest hardened JDK and ensure all third-party libraries, such as Apache Commons Collections, are updated.

@github-actions github-actions Bot Mar 18, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Auto-generated PR comment (Polaris)

Polaris SAST Issue - Insecure Object Deserialization

High CWE-502
The application uses reflection to deserialize data to arbitrary objects by invoking the dangerous load() or loads() functions from the pickle library. If the application passes untrusted data to these functions, an attacker can achieve remote code execution (RCE) by creating malicious serialized objects.

How to fix

The application should avoid using object deserialization for data shared outside a trusted system.

The following things should be taken into consideration for remediation of this issue:

  • Sensitive data should never be included without in serialized state that is sent to a client. If sensitive data is included in serialized state, it must be encrypted with a key that is only available to authorized entities for decrypting the sensitive data.
  • Serialized data must be protected from unauthorized modification, i.e., it should use some form of integrity protection such as a keyed MAC or being digitally signed.
  • Data entering via an untrusted source (e.g., client) should never be deserialized. If this is not possible, then the application must explicitly specify and enforce which classes that should be allowed to be deserialized. It is important to note that it is not sufficient to add validation checks within the class that the application expects to deserialize, as an attacker can create a serialized object of any class they choose, which would then bypass such validation. It is important to strictly control which classes are allowed to be deserialized.

If using Java, it is recommended to use a run-time "agent" such as notsoserial (https://github.com/kantega/notsoserial) to specify and control which classes that should be allowed to be deserialized. Furthermore, it is strongly recommended to use the latest hardened JDK and ensure all third-party libraries, such as Apache Commons Collections, are updated.

return str(obj)

@github-actions github-actions Bot Mar 18, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Auto-generated PR comment (Polaris)

Polaris SAST Issue - Cross-site Scripting

High CWE-79
Untrusted user-supplied data is inserted into a context that can execute JavaScript without adequate validation, escaping, or filtering.

A user can execute arbitrary JavaScript on a web page viewed or accessed by another user, potentially allowing session hijacking, disclosing sensitive data in the DOM, or viewing of keyboard and mouse events.

How to fix

Potential mitigations include the following:

  1. Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.

Examples of libraries and frameworks that make it easier to generate properly encoded output include Microsoft's Anti-XSS library, the OWASP ESAPI Encoding module, and Apache Wicket.

  1. Understand the context in which your data will be used and the encoding that will be expected. This is especially important when transmitting data between different components, or when generating outputs that can contain multiple encodings at the same time, such as web pages or multi-part mail messages. Study all expected communication protocols and data representations to determine the required encoding strategies.

For any data that will be output to another web page, especially any data that was received from external inputs, use the appropriate encoding on all non-alphanumeric characters.

Parts of the same output document may require different encodings, which will vary depending on whether the output is in the:

* HTML body
* Element attributes (such as src="XYZ")
* URIs
* JavaScript sections
* Cascading Style Sheets and style property

etc. Note that HTML Entity Encoding is only appropriate for the HTML body.

Consult the XSS Prevention Cheat Sheet [REF-724] for more details on the types of encoding and escaping that are needed.

  1. Understand all the potential areas where untrusted inputs can enter your software: parameters or arguments, cookies, anything read from the network, environment variables, reverse DNS lookups, query results, request headers, URL components, e-mail, files, filenames, databases, and any external systems that provide data to the application. Remember that such inputs may be obtained indirectly through API calls.
  2. For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
  3. If available, use structured mechanisms that automatically enforce the separation between data and code. These mechanisms may be able to provide the relevant quoting, encoding, and validation automatically, instead of relying on the developer to provide this capability at every point where output is generated.
  4. Use and specify an output encoding that can be handled by the downstream component that is reading the output. Common encodings include ISO-8859-1, UTF-7, and UTF-8. When an encoding is not specified, a downstream component may choose a different encoding, either by assuming a default encoding or automatically inferring which encoding is being used, which can be erroneous. When the encodings are inconsistent, the downstream component might treat some character or byte sequences as special, even if they are not special in the original encoding. Attackers might then be able to exploit this discrepancy and conduct injection attacks; they even might be able to bypass protection mechanisms that assume the original encoding is also being used by the downstream component.

The problem of inconsistent output encodings often arises in web pages. If an encoding is not specified in an HTTP header, web browsers often guess about which encoding is being used. This can open up the browser to subtle XSS attacks.

  1. With Struts, write all data from form beans with the bean's filter attribute set to true.
  2. To help mitigate XSS attacks against the user's session cookie, set the session cookie to be HttpOnly. In browsers that support the HttpOnly feature (such as more recent versions of Internet Explorer and Firefox), this attribute can prevent the user's session cookie from being accessible to malicious client-side scripts that use document.cookie. This is not a complete solution, since HttpOnly is not supported by all browsers. More importantly, XMLHTTPRequest and other powerful browser technologies provide read access to HTTP headers, including the Set-Cookie header in which the HttpOnly flag is set.
  3. Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.

When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."

Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

When dynamically constructing web pages, use stringent allowlists that limit the character set based on the expected value of the parameter in the request. All input should be validated and cleansed, not just parameters that the user is supposed to specify, but all data in the request, including hidden fields, cookies, headers, the URL itself, and so forth. A common mistake that leads to continuing XSS vulnerabilities is to validate only fields that are expected to be redisplayed by the site. It is common to see data from the request that is reflected by the application server or the application that the development team did not anticipate. Also, a field that is not currently reflected may be used by a future developer. Therefore, validating ALL parts of the HTTP request is recommended.

Note that proper output encoding, escaping, and quoting is the most effective solution for preventing XSS, although input validation may provide some defense-in-depth. This is because it effectively limits what will appear in output. Input validation will not always prevent XSS, especially if you are required to support free-form text fields that could contain arbitrary characters. For example, in a chat application, the heart emoticon ("<3") would likely pass the validation step, since it is commonly used. However, it cannot be directly inserted into the web page because it contains the "<" character, which would need to be escaped or otherwise handled. In this case, stripping the "<" might reduce the risk of XSS, but it would produce incorrect behavior because the emoticon would not be recorded. This might seem to be a minor inconvenience, but it would be more important in a mathematical forum that wants to represent inequalities.

Even if you make a mistake in your validation (such as forgetting one out of 100 input fields), appropriate encoding is still likely to protect you from injection-based attacks. As long as it is not done in isolation, input validation is still a useful technique, since it may significantly reduce your attack surface, allow you to detect some attacks, and provide other security benefits that proper encoding does not address.

Ensure that you perform input validation at well-defined interfaces within the application. This will help protect the application even if a component is reused or moved elsewhere.

  1. When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs.
  2. Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth.
  3. When using PHP, configure the application so that it does not use register_globals. During implementation, develop the application so that it does not rely on this feature, but be wary of implementing a register_globals emulation that is subject to weaknesses such as CWE-95, CWE-621, and similar issues.


# Vulnerability 4: Use of Outdated Library with Known Vulnerabilities
@app.route('/requests_example', methods=['GET'])
def requests_example():
response = requests.get('https://example.com')
return response.content

@github-actions github-actions Bot Mar 18, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Auto-generated PR comment (Polaris)

Polaris SAST Issue - Cross-site Scripting

High CWE-79
Untrusted user-supplied data is inserted into a context that can execute JavaScript without adequate validation, escaping, or filtering.

A user can execute arbitrary JavaScript on a web page viewed or accessed by another user, potentially allowing session hijacking, disclosing sensitive data in the DOM, or viewing of keyboard and mouse events.

How to fix

Potential mitigations include the following:

  1. Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.

Examples of libraries and frameworks that make it easier to generate properly encoded output include Microsoft's Anti-XSS library, the OWASP ESAPI Encoding module, and Apache Wicket.

  1. Understand the context in which your data will be used and the encoding that will be expected. This is especially important when transmitting data between different components, or when generating outputs that can contain multiple encodings at the same time, such as web pages or multi-part mail messages. Study all expected communication protocols and data representations to determine the required encoding strategies.

For any data that will be output to another web page, especially any data that was received from external inputs, use the appropriate encoding on all non-alphanumeric characters.

Parts of the same output document may require different encodings, which will vary depending on whether the output is in the:

* HTML body
* Element attributes (such as src="XYZ")
* URIs
* JavaScript sections
* Cascading Style Sheets and style property

etc. Note that HTML Entity Encoding is only appropriate for the HTML body.

Consult the XSS Prevention Cheat Sheet [REF-724] for more details on the types of encoding and escaping that are needed.

  1. Understand all the potential areas where untrusted inputs can enter your software: parameters or arguments, cookies, anything read from the network, environment variables, reverse DNS lookups, query results, request headers, URL components, e-mail, files, filenames, databases, and any external systems that provide data to the application. Remember that such inputs may be obtained indirectly through API calls.
  2. For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
  3. If available, use structured mechanisms that automatically enforce the separation between data and code. These mechanisms may be able to provide the relevant quoting, encoding, and validation automatically, instead of relying on the developer to provide this capability at every point where output is generated.
  4. Use and specify an output encoding that can be handled by the downstream component that is reading the output. Common encodings include ISO-8859-1, UTF-7, and UTF-8. When an encoding is not specified, a downstream component may choose a different encoding, either by assuming a default encoding or automatically inferring which encoding is being used, which can be erroneous. When the encodings are inconsistent, the downstream component might treat some character or byte sequences as special, even if they are not special in the original encoding. Attackers might then be able to exploit this discrepancy and conduct injection attacks; they even might be able to bypass protection mechanisms that assume the original encoding is also being used by the downstream component.

The problem of inconsistent output encodings often arises in web pages. If an encoding is not specified in an HTTP header, web browsers often guess about which encoding is being used. This can open up the browser to subtle XSS attacks.

  1. With Struts, write all data from form beans with the bean's filter attribute set to true.
  2. To help mitigate XSS attacks against the user's session cookie, set the session cookie to be HttpOnly. In browsers that support the HttpOnly feature (such as more recent versions of Internet Explorer and Firefox), this attribute can prevent the user's session cookie from being accessible to malicious client-side scripts that use document.cookie. This is not a complete solution, since HttpOnly is not supported by all browsers. More importantly, XMLHTTPRequest and other powerful browser technologies provide read access to HTTP headers, including the Set-Cookie header in which the HttpOnly flag is set.
  3. Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.

When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."

Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

When dynamically constructing web pages, use stringent allowlists that limit the character set based on the expected value of the parameter in the request. All input should be validated and cleansed, not just parameters that the user is supposed to specify, but all data in the request, including hidden fields, cookies, headers, the URL itself, and so forth. A common mistake that leads to continuing XSS vulnerabilities is to validate only fields that are expected to be redisplayed by the site. It is common to see data from the request that is reflected by the application server or the application that the development team did not anticipate. Also, a field that is not currently reflected may be used by a future developer. Therefore, validating ALL parts of the HTTP request is recommended.

Note that proper output encoding, escaping, and quoting is the most effective solution for preventing XSS, although input validation may provide some defense-in-depth. This is because it effectively limits what will appear in output. Input validation will not always prevent XSS, especially if you are required to support free-form text fields that could contain arbitrary characters. For example, in a chat application, the heart emoticon ("<3") would likely pass the validation step, since it is commonly used. However, it cannot be directly inserted into the web page because it contains the "<" character, which would need to be escaped or otherwise handled. In this case, stripping the "<" might reduce the risk of XSS, but it would produce incorrect behavior because the emoticon would not be recorded. This might seem to be a minor inconvenience, but it would be more important in a mathematical forum that wants to represent inequalities.

Even if you make a mistake in your validation (such as forgetting one out of 100 input fields), appropriate encoding is still likely to protect you from injection-based attacks. As long as it is not done in isolation, input validation is still a useful technique, since it may significantly reduce your attack surface, allow you to detect some attacks, and provide other security benefits that proper encoding does not address.

Ensure that you perform input validation at well-defined interfaces within the application. This will help protect the application even if a component is reused or moved elsewhere.

  1. When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs.
  2. Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth.
  3. When using PHP, configure the application so that it does not use register_globals. During implementation, develop the application so that it does not rely on this feature, but be wary of implementing a register_globals emulation that is subject to weaknesses such as CWE-95, CWE-621, and similar issues.


# Vulnerability 5: SQL Injection
@app.route('/user', methods=['GET'])
def get_user():
user_id = request.args.get('id', '')
query = "SELECT * FROM users WHERE id = '" + user_id + "'"
result = run_query(query) # This function is not defined but simulates a database query
return str(result)

@github-actions github-actions Bot Mar 18, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Auto-generated PR comment (Polaris)

Polaris SAST Issue - Cross-site Scripting

High CWE-79
Untrusted user-supplied data is inserted into a context that can execute JavaScript without adequate validation, escaping, or filtering.

A user can execute arbitrary JavaScript on a web page viewed or accessed by another user, potentially allowing session hijacking, disclosing sensitive data in the DOM, or viewing of keyboard and mouse events.

How to fix

Potential mitigations include the following:

  1. Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.

Examples of libraries and frameworks that make it easier to generate properly encoded output include Microsoft's Anti-XSS library, the OWASP ESAPI Encoding module, and Apache Wicket.

  1. Understand the context in which your data will be used and the encoding that will be expected. This is especially important when transmitting data between different components, or when generating outputs that can contain multiple encodings at the same time, such as web pages or multi-part mail messages. Study all expected communication protocols and data representations to determine the required encoding strategies.

For any data that will be output to another web page, especially any data that was received from external inputs, use the appropriate encoding on all non-alphanumeric characters.

Parts of the same output document may require different encodings, which will vary depending on whether the output is in the:

* HTML body
* Element attributes (such as src="XYZ")
* URIs
* JavaScript sections
* Cascading Style Sheets and style property

etc. Note that HTML Entity Encoding is only appropriate for the HTML body.

Consult the XSS Prevention Cheat Sheet [REF-724] for more details on the types of encoding and escaping that are needed.

  1. Understand all the potential areas where untrusted inputs can enter your software: parameters or arguments, cookies, anything read from the network, environment variables, reverse DNS lookups, query results, request headers, URL components, e-mail, files, filenames, databases, and any external systems that provide data to the application. Remember that such inputs may be obtained indirectly through API calls.
  2. For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
  3. If available, use structured mechanisms that automatically enforce the separation between data and code. These mechanisms may be able to provide the relevant quoting, encoding, and validation automatically, instead of relying on the developer to provide this capability at every point where output is generated.
  4. Use and specify an output encoding that can be handled by the downstream component that is reading the output. Common encodings include ISO-8859-1, UTF-7, and UTF-8. When an encoding is not specified, a downstream component may choose a different encoding, either by assuming a default encoding or automatically inferring which encoding is being used, which can be erroneous. When the encodings are inconsistent, the downstream component might treat some character or byte sequences as special, even if they are not special in the original encoding. Attackers might then be able to exploit this discrepancy and conduct injection attacks; they even might be able to bypass protection mechanisms that assume the original encoding is also being used by the downstream component.

The problem of inconsistent output encodings often arises in web pages. If an encoding is not specified in an HTTP header, web browsers often guess about which encoding is being used. This can open up the browser to subtle XSS attacks.

  1. With Struts, write all data from form beans with the bean's filter attribute set to true.
  2. To help mitigate XSS attacks against the user's session cookie, set the session cookie to be HttpOnly. In browsers that support the HttpOnly feature (such as more recent versions of Internet Explorer and Firefox), this attribute can prevent the user's session cookie from being accessible to malicious client-side scripts that use document.cookie. This is not a complete solution, since HttpOnly is not supported by all browsers. More importantly, XMLHTTPRequest and other powerful browser technologies provide read access to HTTP headers, including the Set-Cookie header in which the HttpOnly flag is set.
  3. Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.

When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."

Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

When dynamically constructing web pages, use stringent allowlists that limit the character set based on the expected value of the parameter in the request. All input should be validated and cleansed, not just parameters that the user is supposed to specify, but all data in the request, including hidden fields, cookies, headers, the URL itself, and so forth. A common mistake that leads to continuing XSS vulnerabilities is to validate only fields that are expected to be redisplayed by the site. It is common to see data from the request that is reflected by the application server or the application that the development team did not anticipate. Also, a field that is not currently reflected may be used by a future developer. Therefore, validating ALL parts of the HTTP request is recommended.

Note that proper output encoding, escaping, and quoting is the most effective solution for preventing XSS, although input validation may provide some defense-in-depth. This is because it effectively limits what will appear in output. Input validation will not always prevent XSS, especially if you are required to support free-form text fields that could contain arbitrary characters. For example, in a chat application, the heart emoticon ("<3") would likely pass the validation step, since it is commonly used. However, it cannot be directly inserted into the web page because it contains the "<" character, which would need to be escaped or otherwise handled. In this case, stripping the "<" might reduce the risk of XSS, but it would produce incorrect behavior because the emoticon would not be recorded. This might seem to be a minor inconvenience, but it would be more important in a mathematical forum that wants to represent inequalities.

Even if you make a mistake in your validation (such as forgetting one out of 100 input fields), appropriate encoding is still likely to protect you from injection-based attacks. As long as it is not done in isolation, input validation is still a useful technique, since it may significantly reduce your attack surface, allow you to detect some attacks, and provide other security benefits that proper encoding does not address.

Ensure that you perform input validation at well-defined interfaces within the application. This will help protect the application even if a component is reused or moved elsewhere.

  1. When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs.
  2. Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth.
  3. When using PHP, configure the application so that it does not use register_globals. During implementation, develop the application so that it does not rely on this feature, but be wary of implementing a register_globals emulation that is subject to weaknesses such as CWE-95, CWE-621, and similar issues.


def run_query(query):
# Simulating a database query without proper sanitization (SQL Injection risk)
return "Query result for: " + query

if __name__ == '__main__':
app.run(debug=True)
11 changes: 11 additions & 0 deletions command_injection_vuln.py
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,11 @@
# command_injection_vuln.py
import os

def ping_host(host):
# Vulnerable to command injection
command = f"ping -c 1 {host}"
os.system(command)

if __name__ == "__main__":
target = input("Enter host to ping: ")
ping_host(target)
11 changes: 11 additions & 0 deletions hardcoded_secret_vuln.py
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,11 @@
# hardcoded_secret_vuln.py

# Hardcoded secrets
API_KEY = "sk_test_1234567890abcdef"
DB_PASSWORD = "SuperSecretPassword123!"

def connect():
print("Connecting with password:", DB_PASSWORD)

if __name__ == "__main__":
connect()
11 changes: 11 additions & 0 deletions insecure_deserialization_vuln.py
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,11 @@
# insecure_deserialization_vuln.py
import pickle

def load_data(serialized_data):
# Insecure deserialization
return pickle.loads(serialized_data)

@github-actions github-actions Bot Mar 18, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Auto-generated PR comment (Polaris)

Polaris SAST Issue - Insecure Object Deserialization

High CWE-502
The application uses reflection to deserialize data to arbitrary objects by invoking the dangerous load() or loads() functions from the pickle library. If the application passes untrusted data to these functions, an attacker can achieve remote code execution (RCE) by creating malicious serialized objects.

How to fix

The application should avoid using object deserialization for data shared outside a trusted system.

The following things should be taken into consideration for remediation of this issue:

  • Sensitive data should never be included without in serialized state that is sent to a client. If sensitive data is included in serialized state, it must be encrypted with a key that is only available to authorized entities for decrypting the sensitive data.
  • Serialized data must be protected from unauthorized modification, i.e., it should use some form of integrity protection such as a keyed MAC or being digitally signed.
  • Data entering via an untrusted source (e.g., client) should never be deserialized. If this is not possible, then the application must explicitly specify and enforce which classes that should be allowed to be deserialized. It is important to note that it is not sufficient to add validation checks within the class that the application expects to deserialize, as an attacker can create a serialized object of any class they choose, which would then bypass such validation. It is important to strictly control which classes are allowed to be deserialized.

If using Java, it is recommended to use a run-time "agent" such as notsoserial (https://github.com/kantega/notsoserial) to specify and control which classes that should be allowed to be deserialized. Furthermore, it is strongly recommended to use the latest hardened JDK and ensure all third-party libraries, such as Apache Commons Collections, are updated.


if __name__ == "__main__":
data = input("Enter serialized object: ")
obj = load_data(data.encode())
print(obj)
15 changes: 15 additions & 0 deletions path_traversal_vuln.py
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,15 @@
# path_traversal_vuln.py
import os

BASE_DIR = "/var/www/files/"

def read_file(filename):
# Vulnerable to path traversal
filepath = os.path.join(BASE_DIR, filename)

with open(filepath, "r") as f:
return f.read()

if __name__ == "__main__":
file = input("Enter filename: ")
print(read_file(file))
19 changes: 19 additions & 0 deletions sql_injection_vuln.py
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,19 @@
# sql_injection_vuln.py
import sqlite3

def get_user(username):
conn = sqlite3.connect("users.db")
cursor = conn.cursor()

# Vulnerable to SQL Injection
query = f"SELECT * FROM users WHERE username = '{username}'"
cursor.execute(query)

result = cursor.fetchall()
conn.close()
return result


if __name__ == "__main__":
user_input = input("Enter username: ")
print(get_user(user_input))
Loading