code-vulnscan

SUSPICIOUS/HIGH-RISK but not malware. The skill is internally coherent for a vulnerability scanner and its data flows are mainly local, but it gives an AI agent substantial offensive security analysis capability, broad access to sensitive repository content, and moderate prompt-injection exposure. Same-org installer evidence lowers maliciousness concerns, though raw GitHub pipe-to-shell remains a supply-chain hygiene risk.

The visible code is a legitimate-looking installer, not direct malware. Its principal security concern is supply-chain trust: it can clone arbitrary repositories, install unreviewed Python dependencies, and place externally sourced instructions into AI-agent configuration directories. The separately downloaded checksum provides integrity against accidental corruption but not strong independent authenticity. Review the omitted helper functions, SKILL.md, requirements.txt, release provenance, and repository contents before use; avoid --install-deps and arbitrary --repo-url sources unless independently verified.

The fragment contains clear examples of authorization vulnerabilities: client-controlled role elevation, an unrestricted destructive user identifier, and IDOR through missing ownership checks. These are security issues in the illustrative code, not evidence of malware in the fragment itself. The JWT examples are dangerous configurations if implemented, but no executable JWT code is provided.

The fragment contains security audit guidance and insecure configuration examples, not malicious executable behavior. Deploying the shown settings would create significant web-application security weaknesses, especially CSRF, session-cookie, clickjacking, information-disclosure, and unauthenticated-service risks. The code itself shows no supply-chain malware indicators.

The fragment contains several potentially severe memory-safety defects, primarily unchecked null or raw-pointer use, invalid slice construction, unsafe transmutation, and unchecked FFI copy lengths. Their exploitability and user-input reachability cannot be confirmed from the truncated material. There is no evidence of malicious supply-chain behavior or intentional obfuscation.

The fragment contains multiple high-impact vulnerabilities: SQL injection, shell command injection leading to possible remote code execution, reflected XSS, arbitrary file read/path traversal, and hardcoded credentials. These appear to be insecure application code rather than deliberate malware, but the package or service should not be deployed without remediation. Use parameterized queries, avoid shell execution or strictly validate arguments, contextually escape output and avoid inline scripts, restrict downloads to an authorized directory, and remove and rotate embedded secrets.

The code contains multiple critical unauthenticated injection and remote-code-execution risks: SQL injection, shell command injection, arbitrary file read, and unsafe pickle deserialization. It also contains hardcoded secret-like credentials. No direct malware payload or data-exfiltration destination is visible, so malicious intent cannot be established; however, the application is extremely unsafe to deploy without substantial remediation.

The code contains a direct SQL injection vulnerability because the client-controlled id parameter is concatenated into a SQL query executed by Statement. It also exposes hardcoded database credentials and has incomplete resource cleanup. Use a PreparedStatement with a typed parameter, externalize and protect credentials, and use try-with-resources.

The code contains clear SQL injection and remote command execution vulnerabilities, plus a hardcoded database credential. It should remain confined to test fixtures and must not be deployed. Use parameterized queries, avoid shell interpretation, validate or eliminate command input, protect command output, and store credentials outside source code.

The code contains a high-confidence path traversal/arbitrary file-read vulnerability because untrusted request input is used directly to construct a filesystem path and the contents are returned to the requester. Use canonical-path validation or resolve against the base directory and verify the normalized result remains within the base directory, along with appropriate authorization checks.

The code contains a high-confidence SQL injection vulnerability because the HTTP query parameter is directly interpolated into a SQL statement. Use a parameterized query such as `db.Query("SELECT * FROM products WHERE name=$1", name)` and avoid exposing raw database errors. No evidence of malicious or obfuscated behavior is present in this fragment.

The controller contains a high-severity SpEL expression-injection vulnerability because it evaluates an HTTP parameter as an unrestricted expression. Do not expose this endpoint with arbitrary expressions. Use a strict allowlist or a non-evaluating rule representation, and if expression evaluation is required, use a restricted evaluation context with tightly limited properties, methods, types, and constructors.

The code contains a high-confidence path traversal vulnerability leading to arbitrary readable-file disclosure. The filename must be constrained to an approved directory and the resolved path verified to remain within that directory. No malicious supply-chain behavior is evident.

The code appears to be a basic S3 client factory, not malware. Its primary security concern is hardcoded AWS credentials, which should be removed and replaced with IAM roles, environment-based credentials, or a secrets manager. Rotate the credentials if they are real or have been exposed.

The code does not show malicious behavior or supply-chain compromise indicators. The SQL query is parameterized and is not directly vulnerable to SQL injection. However, the /login endpoint is insecure because it does not authenticate users and returns all columns for matching accounts, potentially exposing sensitive database data. Confidence is high for this assessment.

The code contains a clear XPath injection vulnerability caused by direct concatenation of the HTTP username parameter into an XPath expression. It should use XPath variables or robust input validation and escaping. No malicious supply-chain behavior is evident in the provided fragment.

The servlet is vulnerable to unsafe Java deserialization because it calls ObjectInputStream.readObject() directly on attacker-controlled HTTP input. This is a high-impact security risk that can enable remote code execution when suitable gadget classes are present. Use a safe, constrained data format such as JSON with strict schema validation, or apply a restrictive ObjectInputFilter and integrity/authentication controls if Java serialization is unavoidable.

The code contains a high-confidence OS command/argument injection vulnerability because attacker-controlled HTTP input is passed directly to Runtime.exec(). It is not clearly malware, but it is unsafe server-side process execution and should be remediated by validating the host against a strict hostname/IP allowlist and using the ProcessBuilder argument-list API with controlled arguments, plus timeouts and resource controls.

The code contains a clear, high-impact SSRF vulnerability because attacker-controlled URL input is passed directly to `http.Get` and the response is relayed to the requester. It should not be exposed without strict destination allowlisting, private-network and metadata-endpoint blocking, redirect controls, authentication, and response limits. The vulnerability appears benchmark-intended rather than malicious package behavior.

The code contains a clear SQL injection vulnerability because the HTTP q parameter is concatenated into an SQL query. It may also disclose database records through the response. No malicious supply-chain behavior or malware indicators are present in the fragment; the primary issue is an application security flaw. Use parameterized SQL such as cursor.execute("SELECT * FROM users WHERE username = ?", (query_str,)).

The code is readable and does not show evidence of malware or intentional sabotage. It implements a file-download/read endpoint with a reasonable lexical traversal check, but it remains a potential arbitrary file disclosure mechanism and is vulnerable to root escape through symlinks or junctions if such filesystem objects can be introduced. Authorization, file allowlisting, size limits, and secure real-path/reparse-point validation should be considered.

The code contains a clear SQL injection vulnerability caused by concatenating the HTTP `name` parameter into a native SQL query. Use a parameterized query such as `createNativeQuery("SELECT * FROM users WHERE name = :name").setParameter("name", name)`. No evidence of malicious package behavior is present.

The code contains a high-impact SQL injection vulnerability because the HTTP name parameter is concatenated directly into a native SQL statement. It does not show evidence of malicious package behavior or intentional obfuscation.

The code does not show clear malware or intentional sabotage. Ordinary shell command injection is substantially mitigated by `shlex.quote`, but the network-facing use of `os.system` and lack of ImageMagick option/path validation create a meaningful security risk, including possible option injection and predictable output-file overwrites.

Critical OS command injection and unauthenticated remote command execution are present. The endpoint should not be deployed. Replace shell execution with a narrowly allowlisted operation and arguments, and add authentication and authorization if an administrative operation is required.

The code is a simple GitHub repository-listing helper, not clear malware. Its primary security issue is hardcoded credential exposure, combined with unvalidated URL construction for the organization input. The token should be revoked if real and replaced with secure configuration such as an environment variable or secret manager; the organization value should be validated or safely encoded. The supplied fragment is also syntactically incomplete.

The code does not show clear malicious behavior or data exfiltration. It does contain plaintext hardcoded database and Redis credentials and directly trusts DATABASE_URL, creating credential-management and configuration-injection risks. Credentials should be removed from source, supplied through a secure secret manager or controlled environment, and connection URLs should be properly validated and URL-encoded. The fragment is also syntactically incomplete as provided.

The code contains a clear SQL injection vulnerability because user-controlled username data is concatenated into a PostgreSQL query. It also risks excessive data exposure by returning SELECT * results and does not implement actual password authentication. The fragment does not provide evidence of intentional malware or supply-chain sabotage; the primary issue is insecure application code.

The code contains a clear LDAP injection vulnerability because untrusted `uid` input is concatenated into an LDAP filter without escaping. Use Spring LDAP filter-building or escaping APIs, validate the expected UID format, and restrict returned attributes and authorization as appropriate. No evidence of malicious package behavior is present.

The code is a simple file-serving endpoint and does not show evidence of intentional malware. It has a significant path traversal vulnerability because client-controlled input is used directly in a filesystem path. Restrict the resolved path to /var/data, reject traversal and absolute paths, use a safe path-joining check, and set appropriate response content headers.

The code contains a direct, high-confidence SSRF vulnerability because untrusted input controls an outbound HTTP request and its response is exposed to the requester. It is insecure as implemented, but there is no evidence of malicious package behavior or intentional malware.

The code contains a high-confidence SQL injection vulnerability because untrusted HTTP input is concatenated into a PostgreSQL query. Use a parameterized query such as `sqlx::query("SELECT * FROM users WHERE name = $1").bind(&query.name)`. The fragment shows no evidence of malware or supply-chain attack behavior.

The code does not show intentional malware, but it contains a clear SQL injection vulnerability because the request-controlled `id` is directly interpolated into the SQL query. It also potentially exposes all columns of a user record and lacks authorization checks. Use a parameterized query such as `cursor.execute("SELECT * FROM users WHERE id = ?", (uid,))`, validate the identifier, and return only permitted fields.

The code contains a clear SQL injection vulnerability because the name query parameter is concatenated into the SQL statement. Query results are also returned directly to the client, which can amplify data exposure. No evidence of intentional malware or supply-chain compromise is present in this fragment.

The code contains a reflected cross-site scripting vulnerability because the attacker-controlled q parameter is written directly to the response without HTML escaping. This is a security defect, not evidence of package malware or intentional malicious behavior.

The code contains a critical OS command injection vulnerability. Any network client able to reach port 3000 can likely execute arbitrary shell commands through the cmd query parameter and receive their standard output. Replace shell execution with a non-shell filesystem API such as fs.readdir, or strictly allowlist permitted directory inputs and use a safe process-spawning API without shell interpretation. Malware intent is not evident from this fragment, but the security risk is extremely high.

The fragment is not evidence of malware, but it contains a potentially dangerous XML parsing configuration. Explicitly enabling XmlUrlResolver for untrusted input creates a credible XXE/SSRF risk if external entity or DTD processing is enabled in the effective environment; lack of resource limits also creates denial-of-service exposure. Configure XmlResolver = null, prohibit DTD processing, and enforce request and parser limits.

The code contains a security-relevant untrusted deserialization and denial-of-service risk, primarily due to fully buffering a large attacker-controlled body and panicking on deserialization failure. The save operation and Import definition require review for validation and downstream injection risks. The fragment does not show malware or deliberate malicious behavior.

The code contains a high-confidence SQL injection vulnerability because the query-string value `term` is directly interpolated into a SQL command. Use a parameterized query such as `WHERE name = @term`, restrict returned columns, materialize and authorize the result set, and dispose of the command and reader appropriately. The fragment does not show malicious supply-chain behavior, but it poses a significant security risk when deployed.

The code contains a high-confidence open redirect vulnerability because an attacker-controlled request parameter is used directly as the redirect destination. It does not show evidence of intentional malware or supply-chain sabotage. Redirect targets should be restricted to approved relative paths or an explicit host allowlist.

The fragment is ordinary legacy database code, not apparent malware. It contains a high-impact SQL injection vulnerability due to unsanitized $_GET input, uses insecure hardcoded root credentials with a blank password, and may expose an XSS risk through unescaped output. Replace mysql_* APIs with PDO or mysqli prepared statements, use a least-privileged database account with a strong secret, validate id as an integer, and HTML-escape output.

The fragment contains a clear SQL injection vulnerability because untrusted `query.email` input is concatenated into raw SQL. This is a security risk but there is no evidence of intentional malware or supply-chain sabotage in the provided code.

The code contains a high-impact OS command injection vulnerability in the `/ping` endpoint. It is not clearly malware by intent, but it is unsafe for deployment because remote users can potentially execute arbitrary shell commands through the `host` parameter and receive their output. Use argument-list execution with `shell=False` and strict host validation.

The code is a small Express search endpoint with a high-impact reflected XSS vulnerability caused by inserting untrusted q input into a JavaScript and HTML response without encoding. No malicious package behavior is evident; the risk is an unsafe application coding pattern rather than malware.

The code contains a critical OS command-injection vulnerability: an HTTP query parameter is executed verbatim by sh -c. This enables arbitrary command execution if the route is reachable. The fragment does not itself demonstrate intentional malware, but deploying it creates a high-risk remote code execution surface.

The code contains a likely open-redirect vulnerability: attacker-controlled query data is written directly to the `Location` header. Validate that `next` is a safe relative path or matches an explicit allowlist of trusted origins before redirecting. No evidence of malicious supply-chain behavior or malware is present in this fragment.

The code is not indicative of malware, but it contains a reflected XSS vulnerability because attacker-controlled query-string data is marked safe and directly embedded in HTML. The input should be escaped rather than wrapped in `Markup`; using Flask/Jinja templating with default autoescaping is preferable. If the missing f-string quote is literal, the code also has a syntax error.

The endpoint is vulnerable to server-side template injection because user input is concatenated into a template passed to `render_template_string`. Use a static template such as `render_template_string('<h1>Hello, {{ name }}!</h1>', name=name)` or a template file with variables. The fragment does not itself demonstrate malware, but the vulnerability presents a high security risk if remotely reachable.

The endpoint contains a high-severity unsafe deserialization vulnerability. It deserializes attacker-controlled HTTP input with BinaryFormatter, which should not be used for untrusted data and can enable remote code execution through gadget chains. Replace it with a strictly typed, allowlisted serialization format such as System.Text.Json and enforce authentication, authorization, size limits, and schema validation.

The code contains a clear SSRF vulnerability: an attacker can cause the server to make HTTP requests to arbitrary destinations. It is not inherently evidence of intentional malware, but it presents a significant application security risk and should be mitigated with strict destination allowlisting, scheme and port restrictions, private-address blocking, redirect validation, and appropriate timeout and response handling.

The code contains a likely arbitrary file read/path traversal vulnerability. An attacker may be able to request files outside the intended storage directory using traversal or rooted paths, and the endpoint exposes their contents. The fragment does not provide evidence of intentional malware, but it presents a significant security risk if reachable by untrusted or unauthenticated users. Remediation should canonicalize and validate the resolved path against the canonical storage root, restrict allowed filenames, handle errors safely, and enforce authorization.

The code contains a high-severity OS command injection vulnerability because the HTTP-controlled `filename` value is passed unsafely to `os.system()`. It is not itself clear evidence of intentionally malicious package behavior, but exposing this endpoint could enable arbitrary command execution. Use a safe subprocess invocation with an argument list, strict filename/path validation, and appropriate process restrictions.

The code contains an arbitrary local file read/path traversal vulnerability because attacker-controlled input is used directly as a filesystem path. The incomplete return statement makes the exact fragment nonfunctional, but the intended endpoint would disclose any readable file accessible to the Flask process. No clear malicious supply-chain behavior or intentional malware is present.

The fragment contains a clear SSRF-prone data flow because an untrusted query parameter controls the outbound request URI. The immediate code does not itself perform network access, but it is unsafe if the returned request is subsequently dispatched without destination validation. No evidence of intentional malware or supply-chain sabotage is present.

This is a path traversal risk in a file-download handler. The user-controlled route value is used directly in a filesystem path without containment validation. Use a safe filename/path API, reject traversal and absolute paths, and canonicalize the candidate path before confirming it is under the intended directory. No evidence of malicious intent or malware is present.

The code exposes an unauthenticated remote-code-execution risk by deserializing HTTP request data with pickle.loads. It should not deserialize untrusted input with pickle; use a safe format such as JSON with strict schema validation, or authenticate and cryptographically verify trusted serialized data before processing. The fragment also has a syntax error due to the incomplete return statement.

The code exposes unauthenticated-looking arbitrary remote shell command execution through the POST /run endpoint. It should not be deployed. Replace shell execution with a narrowly allowlisted operation implemented without a shell, and enforce authentication, authorization, least privilege, auditing, and resource limits.

The code contains a reflected XSS vulnerability because the query parameter is inserted into an HTML response without escaping. Use HTML escaping or a templating library with context-appropriate automatic escaping. No evidence of malicious package behavior or intentional malware is present.

The code contains a clear server-side template injection vulnerability because attacker-controlled input is passed directly to Tera for evaluation. The fragment does not itself show malware or data exfiltration, but exploitation may enable unintended template evaluation and potentially disclosure or other impact depending on the Tera version, configuration, and surrounding application code.

The code contains a significant SSRF vulnerability because an untrusted URL is passed directly to `requests.get` and the fetched content is intended to be returned. It does not show clear malicious package behavior, but it is unsafe application code and should use strict URL validation, destination allowlisting, network egress controls, redirect handling, response limits, and request timeouts.

The code implements an unrestricted server-side URL fetcher. It presents a high-confidence SSRF vulnerability and a secondary resource-exhaustion risk because attacker-controlled input directly determines the outbound destination and the full response is buffered. Restrict targets to approved schemes and hosts, block loopback/private/link-local ranges after DNS resolution, control redirects, enforce authentication, timeouts, and response-size limits, and avoid exposing arbitrary fetched content.

The code contains a clear server-side request forgery vulnerability because an untrusted query parameter directly controls an outbound HTTP request and its response is exposed. This is a security flaw, but the fragment provides no evidence of intentional malware or supply-chain abuse. Restrict destinations using an allowlist, reject loopback/private/link-local/reserved addresses after DNS resolution, constrain schemes and ports, handle redirects safely, and apply timeouts and response-size limits.

The code contains a potential XSS vulnerability because untrusted component input is rendered as raw HTML through MarkupString. Content should remain a normal string for automatic encoding or be sanitized with a well-reviewed HTML sanitizer before rendering. No evidence of malware, data theft, obfuscation, or supply-chain sabotage is present in this fragment.

The code contains a likely open redirect vulnerability because an untrusted query parameter is used directly as the redirect destination. No evidence of malicious package behavior or malware is present in this fragment. The endpoint should validate that returnUrl is a local URL or belongs to an approved allowlist.

The code contains a clear SQL injection vulnerability because untrusted $_GET['status'] is directly concatenated into a database query. No evidence of intentional malware or supply-chain backdoor behavior is present in this fragment. The missing semicolon may make the fragment syntactically incomplete.

The fragment contains a direct user-input-to-outbound-request flow and is vulnerable to Server-Side Request Forgery unless the URL is strictly validated and restricted. There is no clear evidence of intentional malware, but deployment without network and URL controls can expose internal services and sensitive metadata.

The fragment contains a high-impact PHP object-injection risk because attacker-controlled cookie data is unserialized directly. Exploitability depends on available classes and gadget chains elsewhere in the application. The snippet does not by itself demonstrate malicious intent or malware, but it should not be used as written.

The code is a simple greeting handler with a reflected XSS vulnerability because $_GET["name"] is echoed without HTML escaping. Use htmlspecialchars($name, ENT_QUOTES, 'UTF-8') before output. No evidence of malware or supply-chain sabotage is present.

The fragment contains a reflected or stored XSS risk depending on how the request value is subsequently used. Replace {!! request('bio') !!} with escaped output such as {{ request('bio') }} or apply context-appropriate, trusted sanitization when limited HTML is intentionally allowed. The code does not indicate malware or supply-chain behavior.

The code contains a critical unauthenticated local file inclusion vulnerability and may permit remote file inclusion or arbitrary PHP code execution depending on server configuration and available files. The include target must be restricted using a fixed allowlist or safe mapping of identifiers to known files; directly including user input is unsafe.

No evidence of malicious behavior or supply-chain malware is present. The code has a potential mass-assignment and input-validation risk because all request fields are persisted unless the model enforces appropriate attribute protection. Use an explicit allowlist of permitted fields and enforce authorization and validation.

The code contains a clear SQL injection vulnerability because request-controlled input is interpolated directly into a Rails SQL condition. It is a security flaw but there is no evidence in this fragment of intentional malware or supply-chain sabotage.

This is a Rails mass-assignment vulnerability caused by permitting all user-supplied attributes. Replace permit! with an explicit allowlist of intended fields. The code shows a security flaw but no evidence of malicious package behavior.

The code is a high-confidence command-injection web shell. Any unauthenticated request capable of reaching this endpoint can execute arbitrary operating-system commands with the PHP process privileges. It should not be deployed; remove it and investigate the host for compromise.

The fragment contains a direct Rails XSS risk because untrusted params[:bio] is passed to raw(). It does not show evidence of intentional malware or supply-chain abuse, but the incomplete context prevents determining whether the value is actually emitted in a response.

This code contains an unsafe deserialization vulnerability. Do not pass attacker-controlled data to `Marshal.load`; use a safe, constrained serialization format such as JSON with explicit schema validation, or verify authenticity and strictly constrain deserialization before processing.

The code contains a likely Rails SSRF vulnerability because an untrusted request parameter directly controls an outbound HTTP request. It should validate and allowlist schemes and destinations, block loopback/private/link-local and metadata addresses, restrict ports, and apply timeouts. No evidence of malware is present in this fragment.

The code contains a clear path traversal/arbitrary file disclosure vulnerability because an HTTP parameter is passed directly to send_file. It should restrict paths to an approved directory, canonicalize and verify containment, and enforce authorization. No malicious payload, exfiltration logic, or obfuscation is present in this fragment.

The fragment contains a likely Rails open redirect because untrusted request input is passed directly to `redirect_to`. Validate that the destination is a safe relative path or matches an explicit host allowlist before redirecting. No malicious supply-chain behavior is evident in this fragment.