Is a 500 Error with the “digest” response body still a reliable vulnerability indicator?

[rafael-tanaka]

Some security consultants claim that my app is still vulnerable because it returns a 500 error along with the well-known “digest” payload in the response body. However, the fix-react2shell-next tool reports no vulnerabilities. Even so, when using the following curl command (shared across multiple security websites), the app still returns a 500 error with the expected “digest” response.
My question is whether this combination of a 500 error and a “digest” response can still be considered a reliable vulnerability indicator, given that my Next.js and React versions are already patched and fix-react2shell-next does not report any issues.

Automated security tools like Wiz and Snyk didn't report any vulnerabilities.

Steps to reproduce: Run the following curl command against any patched app, and it will still return a 500 error with the “digest” response in the body.

CURL:

curl -i 'https://yourwebsite.com/' \
  -X POST \
  -H 'User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36 Assetnote/1.0.0' \
  -H 'Next-Action: x' \
  -H 'X-Nextjs-Request-Id: b5dce965' \
  -H 'Next-Router-State-Tree: %5B%22%22%2C%7B%22children%22%3A%5B%22__PAGE__%22%2C%7B%7D%2Cnull%2Cnull%5D%7D%2Cnull%2Cnull%2Ctrue%5D' \
  -H 'Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryx8jO2oVc6SWP3Sad' \
  -H 'X-Nextjs-Html-Request-Id: SSTMXm7OJ_g0Ncx6jpQt9' \
  --data-binary $'------WebKitFormBoundaryx8jO2oVc6SWP3Sad\nContent-Disposition: form-data; name="1"\n\n{}\n------WebKitFormBoundaryx8jO2oVc6SWP3Sad\nContent-Disposition: form-data; name="0"\n\n["$1:a:a"]\n------WebKitFormBoundaryx8jO2oVc6SWP3Sad--\n'

package.json:

{
  "name": "my-app",
  "private": true,
  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "next start"
  },
  "dependencies": {
    "next": "16.0.7",
    "react": "19.2.1"
  },
  "devDependencies": {
    "@types/node": "22.7.4",
    "@types/react": "19.0.2",
    "typescript": "5.6.3"
  }
}