How to fix uppy vulnerability in ABP 8.2.3 #10670

4 Answer(s)

• 

  0

  AI-Bot created 4 months ago

  Support Team ABP Agent

  • Yes, you can mitigate it without upgrading ABP Framework, because this is an NPM transitive dependency (frontend build-time/runtime) and is not tied to your server-side ABP NuGet packages. The usual approach is to force a patched uppy version via your package manager’s override mechanism.

  • Recommended mitigation: force/override uppy (and/or @uppy/*) to a fixed version

    1. If you use npm (package-lock.json) add an override in your React app’s package.json:

  {
         "overrides": {
           "uppy": "3.27.4"
         }
       }
  

   Then:
  

  rm -rf node_modules package-lock.json
       npm install
       npm ls uppy
  

  2. If the dependency is actually @uppy/* packages (common in ABP UI packages), pin those too:

  {
         "overrides": {
           "uppy": "3.27.4",
           "@uppy/core": "3.27.4",
           "@uppy/dashboard": "3.27.4"
         }
       }
  

   (Adjust the versions to a known-fixed version that satisfies your vulnerability scanner and dependency tree.)
  

  3. If you use yarn use resolutions instead:

  {
         "resolutions": {
           "uppy": "3.27.4"
         }
       }
  

   Then reinstall and verify with `yarn why uppy`.
  

  • Can it be safely overridden?

    • In practice, yes: ABP React UI packages don’t require a specific Uppy patch version unless there’s a breaking change. A patch/minor bump is typically safe, but you must confirm by running your UI build and any upload/file-related flows you use.

  • Configuration-based mitigations?

    • For a dependency-level vulnerability like this, there is no ABP configuration switch that “fixes” it. The mitigation is dependency patching (override/pin) or removing the feature/package that brings Uppy in.
    • If your scanner flags it but you do not actually use any Uppy-based upload UI at runtime, you can also consider removing the upstream package that pulls it in (if possible in your setup). That’s still dependency management, not ABP config.

  • Note about sources

    • No verified ABP-specific source was available for “uppy vulnerability mitigation” in ABP v8.2.3 from the provided tools/context.

  ---

  This response was generated by AI. If it didn’t solve your problem, feel free to post a new answer — our support team will jump in to help you soon.

  Markdown supported.

  Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)

  Save Cancel
• 

  0

  maliming created 4 months ago

  Support Team Fullstack Developer

  Hi,

  Quick context: in ABP 8.2.3, the @abp/uppy npm wrapper declares "uppy": "^3.0.0", and npm resolves that to the latest 3.x — which is 3.27.3. The wrapper has no JS code of its own; it just copies node_modules/uppy/dist/* to wwwroot/libs/uppy/ via abp.resourcemapping.js. So you can change the resolved uppy version without touching ABP server-side (NuGet) packages.

  Two important signals before we pick a fix:

  1. Your report shows uppy@3.27.3 (Transitive). In most SCA tools, (Transitive) means uppy is brought in through another package (here, @abp/uppy). The finding can either be in uppy's own code or in one of uppy's own sub-dependencies, and scanners often display the top-level package as the "vulnerable" one.
  2. The public databases we can check do not flag uppy@3.27.3 itself:
     • Snyk: https://security.snyk.io/package/npm/uppy/3.27.3 — "No direct vulnerabilities have been found for this package."
     • GitHub Advisory Database / NVD: no advisory matching uppy + CWE-843.

  This strongly suggests the actual vulnerable package is a sub-dependency of uppy, not uppy itself. To pinpoint it, please share:

  • Output of npm ls uppy (full chain, so we can confirm whether it comes through @abp/uppy or something else)
  • The exact advisory ID from your scanner (CVE / GHSA / SNYK-ID), and ideally the "vulnerable package" field — that one is the package you actually need to bump, not necessarily uppy

  While you collect those, here are the upgrade paths in order of safety:

  Option 1 — Bump only the @abp/* npm packages to ~8.3.x (recommended). Keep ABP NuGet at 8.2.3. @abp/uppy@~8.3.x declares "uppy": "^3.27.0", so you stay on the 3.x line and just get the latest 3.27 patch. This is the smallest change and may already pull a fresh enough sub-dependency to clear the finding.

  # In your client project, change @abp/* packages to ~8.3.x in package.json, then:
  rm -rf node_modules package-lock.json
  npm install
  npm ls uppy
  

  Option 2 — npm overrides to pin the actual vulnerable package. Once you know which sub-dependency the scanner is flagging, override that one directly (not necessarily uppy). Example shape:

  {
    "overrides": {
      "<the-actual-vulnerable-package>": "<fixed-version>"
    }
  }
  

  If the scanner really is flagging uppy itself, pin uppy to the latest 3.x patch and stay on the 3.x major.

  Don't blindly jump to uppy@4.x or 5.x via overrides. Uppy 4.x went ESM-only and 5.x changed bundle/plugin internals further. ABP's MVC pages call Uppy.Dashboard, Uppy.XHRUpload, uppy.use(), etc. via the global bundle, and although ABP itself moved to uppy 4 in v9.0 and uppy 5 in v10.0, that came with corresponding npm-pack updates and library-refresh runs (abp install-libs). Overriding the major across a wrong @abp/uppy version risks runtime errors in upload UI (file-management, cms-kit-admin, identity user import, account profile picture, etc.).

  For reference, this is how ABP itself has moved uppy:

  | @abp/uppy version | uppy range | | --- | --- | | 8.0.x – 8.2.x | ^3.0.0 | | 8.3.x | ^3.27.0 | | 9.x | ^4.4.1 | | 10.x | ^5.1.2 |

  Also note: there is no ABP configuration switch that mitigates an npm-level vulnerability. It is purely a dependency-version question. If your client app does not actually use any Uppy-based upload UI at runtime, removing the package that pulls it in is also an option, but again npm ls uppy is the first step to know what to remove.

  Thanks

  Markdown supported.

  Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)

  Save Cancel
• 

  0

  priyankasynapxe created 4 months ago

  [maliming] said: Hi,

  Quick context: in ABP 8.2.3, the @abp/uppy npm wrapper declares "uppy": "^3.0.0", and npm resolves that to the latest 3.x — which is 3.27.3. The wrapper has no JS code of its own; it just copies node_modules/uppy/dist/* to wwwroot/libs/uppy/ via abp.resourcemapping.js. So you can change the resolved uppy version without touching ABP server-side (NuGet) packages.

  Two important signals before we pick a fix:

  1. Your report shows uppy@3.27.3 (Transitive). In most SCA tools, (Transitive) means uppy is brought in through another package (here, @abp/uppy). The finding can either be in uppy's own code or in one of uppy's own sub-dependencies, and scanners often display the top-level package as the "vulnerable" one.
  2. The public databases we can check do not flag uppy@3.27.3 itself:
     • Snyk: https://security.snyk.io/package/npm/uppy/3.27.3 — "No direct vulnerabilities have been found for this package."
     • GitHub Advisory Database / NVD: no advisory matching uppy + CWE-843.

  This strongly suggests the actual vulnerable package is a sub-dependency of uppy, not uppy itself. To pinpoint it, please share:

  • Output of npm ls uppy (full chain, so we can confirm whether it comes through @abp/uppy or something else)
  • The exact advisory ID from your scanner (CVE / GHSA / SNYK-ID), and ideally the "vulnerable package" field — that one is the package you actually need to bump, not necessarily uppy

  While you collect those, here are the upgrade paths in order of safety:

  Option 1 — Bump only the @abp/* npm packages to ~8.3.x (recommended). Keep ABP NuGet at 8.2.3. @abp/uppy@~8.3.x declares "uppy": "^3.27.0", so you stay on the 3.x line and just get the latest 3.27 patch. This is the smallest change and may already pull a fresh enough sub-dependency to clear the finding.

  # In your client project, change @abp/* packages to ~8.3.x in package.json, then: 
  rm -rf node_modules package-lock.json 
  npm install 
  npm ls uppy 
  

  Option 2 — npm overrides to pin the actual vulnerable package. Once you know which sub-dependency the scanner is flagging, override that one directly (not necessarily uppy). Example shape:

  { 
    "overrides": { 
      "<the-actual-vulnerable-package>": "<fixed-version>" 
    } 
  } 
  

  If the scanner really is flagging uppy itself, pin uppy to the latest 3.x patch and stay on the 3.x major.

  Don't blindly jump to uppy@4.x or 5.x via overrides. Uppy 4.x went ESM-only and 5.x changed bundle/plugin internals further. ABP's MVC pages call Uppy.Dashboard, Uppy.XHRUpload, uppy.use(), etc. via the global bundle, and although ABP itself moved to uppy 4 in v9.0 and uppy 5 in v10.0, that came with corresponding npm-pack updates and library-refresh runs (abp install-libs). Overriding the major across a wrong @abp/uppy version risks runtime errors in upload UI (file-management, cms-kit-admin, identity user import, account profile picture, etc.).

  For reference, this is how ABP itself has moved uppy:

  | @abp/uppy version | uppy range | | --- | --- | | 8.0.x – 8.2.x | ^3.0.0 | | 8.3.x | ^3.27.0 | | 9.x | ^4.4.1 | | 10.x | ^5.1.2 |

  Also note: there is no ABP configuration switch that mitigates an npm-level vulnerability. It is purely a dependency-version question. If your client app does not actually use any Uppy-based upload UI at runtime, removing the package that pulls it in is also an option, but again npm ls uppy is the first step to know what to remove.

  Thanks

  Hi,

  Thanks for the detailed explanation. The vulnerability flagged by our scanner is CVE-2025-70023, affecting uppy@3.27.3, which is currently resolved as a transitive dependency in our project. At the moment, the scanner indicates that no remediated (fixed) version is available yet. Based on this, I would like to clarify a few points:

  Since there is no patched version available upstream, is there any recommended mitigation approach from ABP’s side (temporary or compensating control)? Would it be advisable to remove or replace @abp/uppy entirely if the functionality is not actively used, to eliminate the vulnerable dependency? Are there any safe workarounds (e.g., restricting features, usage patterns, or runtime configurations) that could reduce the risk exposure until an official fix is released? Lastly, does ABP have any planned update or advisory regarding this CVE for upcoming releases?

  We understand this is an upstream issue, but any guidance on minimizing risk within the current ABP 8.2.3 setup would be very helpful. Thanks in advance for your support.

  Markdown supported.

  Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)

  Save Cancel
• 

  0

  maliming created 4 months ago

  Support Team Fullstack Developer

  Hi,

  Thanks for the CVE number. Looking at the public record, the picture is different from what your scanner is showing — this is very likely not an actual exposure for your uppy@3.27.3:

  • NVD record for CVE-2025-70023 names only transloadit uppy v0.25.6 (a 2017–2018 0.x release): https://nvd.nist.gov/vuln/detail/CVE-2025-70023
  • GitHub advisory GHSA-pw2f-q928-88j2 lists affected versions: Unknown and patched versions: Unknown: https://github.com/advisories/GHSA-pw2f-q928-88j2
  • The only reference is a sparse gist with no PoC, no code path, no attack vector: https://gist.github.com/zcxlighthouse/27926a85371ac5d2291f44903254753e
  • Snyk explicitly says uppy@3.27.3 has no direct vulnerabilities: https://security.snyk.io/package/npm/uppy/3.27.3
  • The Uppy upstream repo has no issue, PR, or advisory acknowledging this CVE
  • The CVSS 9.8 score on the CVE was auto-assigned by CISA-ADP from the description string, not from an analyzed attack chain

  Even setting the version-range question aside: uppy is a client-side file picker / uploader library that runs in the end user's own browser. A CWE-843 (type confusion) bug in that context, at worst, lets a malicious page or local script crash or misbehave inside the user's own tab during an upload. It is not a server-side RCE, not a cross-user attack, and it does not bypass the ABP server's authentication, authorization, or BlobStoring layer that the file ultimately goes through. The 9.8 Critical rating is a description-pattern artifact, not a real-world severity for this context.

  To your questions:

  1. Is mitigation needed from ABP's side?

  There is no evidence uppy@3.27.3 is affected, and even if it were, the realistic blast radius in a client-side uploader is small. The most defensible action is to push back on the finding with your scanner vendor as a likely false positive and cite the six points above. Most SCA vendors accept disputes when the CVE description itself does not cover the version they are flagging.

  2. Should we remove @abp/uppy entirely?

  We do not recommend removing it. @abp/uppy is the resource source for several ABP upload features that ship with the framework: File Management module, CMS Kit blog/page editor image upload, Identity user bulk import, and Account profile picture. Removing the package will break those UIs as soon as anyone hits them.

  3. Safe workarounds / compensating controls.

  Realistically, there isn't a targeted one. The CVE itself describes no exploit path, so there is no specific configuration to harden. And several ABP upload surfaces are intentionally open to all authenticated users (Account profile picture, CMS Kit editor image upload for content authors), so permission revocation isn't a generic answer either.

  The only meaningful server-side knob in 8.2.3 is FileManagement.FileDescriptor.Create permission, which you can revoke per role for the File Management module. The Account profile picture and CMS Kit editor flows don't have an equivalent ABP-level whitelist switch. If you wanted to apply a hard whitelist at the HTTP layer (allowed extensions / MIME types) you'd implement that yourself in a middleware or action filter — it is not built in.

  In short: don't expect to find a meaningful "ABP-side mitigation" for this CVE, because the CVE doesn't describe what we'd be mitigating against.

  4. ABP's plan around this CVE.

  ABP has already moved uppy forward in newer releases on its normal cadence:

  • ABP 8.3.x → uppy ^3.27.0
  • ABP 9.x → uppy ^4.4.1
  • ABP 10.x (current 10.4) → uppy ^5.1.2

  Since uppy@3.27.3 is not confirmed vulnerable by any public record, there is no planned 8.2.x security patch specifically for CVE-2025-70023. If the CVE ever gets a real entry with a confirmed 3.x range and a fixed version, we will follow up.

  If your compliance process still requires a recorded action on the finding, here are two low-impact options that don't touch ABP server-side at all:

  Option 1 — refresh your lockfile. Your uppy@3.27.3 is whatever your package-lock.json froze at install time. The 3.x line has one final patch after that, uppy@3.27.4 (2024-08-21). A clean reinstall picks it up:

  rm -rf node_modules package-lock.json
  npm install
  npm ls uppy
  

  Option 2 — pin the version explicitly. Some scanners prefer to see an explicit pin as a compliance signal. Add an override in your package.json:

  {
    "overrides": {
      "uppy": "3.27.4"
    }
  }
  

  For yarn, use resolutions with the same value. Do not pin to 4.x or 5.x via overrides — Uppy 4.x went ESM-only and the bundle/plugin internals changed; ABP 8.2.3's MVC pages call Uppy.Dashboard / Uppy.XHRUpload via the global bundle, and crossing majors here will break the upload UIs.

  Thanks

  Markdown supported.

  Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)

  Save Cancel