v2.27.2

[prafull-opensignlabs]

No description provided.

To fix the security issue, instead of checking if 'amazonaws.com' is present anywhere in the endpoint string, you should parse the endpoint as a URL (using the URL constructor) and check whether the hostname exactly matches or ends with 'amazonaws.com'. This ensures that only real AWS endpoints are detected, and trick endpoints (e.g., those with 'amazonaws.com' in a different part of the URL or as a subdomain of an unrelated host) are not falsely classified as AWS endpoints.

• Update line 22 of createS3Client to parse endpoint with new URL(...) and check its hostname.
• Use either:
  • endpointHostname === 'amazonaws.com' or
  • endpointHostname.endsWith('.amazonaws.com') or
  • endpointHostname === 'amazonaws.com' || endpointHostname.endsWith('.amazonaws.com')
• If endpoint does not parse as a URL, fallback gracefully (ignore custom endpoint).
• No additional imports are needed.
• Only lines inside the function createS3Client need changes.

---

To fix the vulnerability, any user-supplied value that is included in HTML output must be properly escaped for the appropriate context. Since userId ends up embedded in an HTML attribute value (the action attribute of a form), we need to use an HTML-escaping function. The best and most robust way is to use a mature and well-tested escaping library such as escape-html.

Steps to fix:

• Import the escape-html package at the top of the file.
• When building the htmlForm string on line 265–346, wrap userId with the escaping function when interpolating it in the string:
  action="${routePath}/delete-account/${escapeHtml(userId)}"
• This will ensure that any HTML special characters in userId (such as ", <, >, &) are properly encoded, preventing XSS.

Only the relevant block needs to be changed, and the required import added at the top.

---

To fix this issue, we must sanitize or escape the userId prior to including it in the HTML response. Since the context is within an HTML "href" attribute, the value must be escaped to prevent breaking the attribute or enabling script execution via malformed values. The best, simplest way is to use a well-known HTML-escaping utility such as escape-html. This library safely escapes HTML special characters, preventing injection attacks.

Implementation steps:

• Add the escape-html import at the top of the file.
• When building errorMessage, apply escape() to userId before interpolating it into the HTML anchor.
• No changes to the actual business logic or user IDs.

---

To fix the XSS vulnerability, any error message or user-controllable string sent as part of a server response with HTML or text content must be properly escaped before being sent to the client. The most robust approach is to encode HTML meta-characters (<, >, &, ", ', /) in the error message such that if the message is rendered in a browser, it can't be interpreted as HTML or JavaScript. This can be accomplished by using a standard library such as he or escape-html, which specifically escapes HTML characters. The replacement should be at the point where the error message is being sent to clients, i.e., inside the catch block on line 409. Add the relevant import at the top of the file.

Required changes:

1. Add an import for an HTML-escaping function (such as from the escape-html package).
2. Before sending errorMessage, ensure it is properly escaped.
3. Only touch the lines sending the error message (res.status(500).send(errorMessage); → escape before send).
4. No other functionality should change.

---

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Updated (UTC)
open-sign	Ready	Preview	Sep 8, 2025 5:01am