The vulnerability allows unauthenticated users to access sensitive project data, including server-side scripts and device configurations, via the /api/project endpoint. This is caused by a combination of two main issues.\n\nFirst, as described in the security advisory, the application's authentication middleware (secureFnc and verifyToken in server/api/jwt-helper.js) would automatically generate a guest-level JWT for requests without a token. This effectively authenticated any unauthenticated user as a 'guest'.\n\nSecond, once 'authenticated' as a guest, the getProject function in server/runtime/project/index.js was called to retrieve the project data. This function, in turn, used the _filterProjectPermission function to filter the data based on the user's permissions. However, the vulnerable version of _filterProjectPermission did not properly filter sensitive data for guest users. Specifically, as shown in commit 59c5f7ff415d2c704e2a32e9d9f47c0e3bb2c901, it failed to remove the source code of server-side scripts (script.code) from the project data. This resulted in the full project data, including sensitive scripts, being returned to the unauthenticated user.\n\nAdditionally, a related authorization bypass was fixed in the isAuthorisedByScriptName function in server/runtime/scripts/index.js (commit 78534da61a91613712b44bb63c8d7da8c5df5ca4). This function would incorrectly return true (authorized) if a requested script did not exist, which could be used to bypass security checks.\n\nThe primary vulnerable function is _filterProjectPermission because it was the last line of defense and failed to protect the sensitive data from the guest user. The isAuthorisedByScriptName function represents another weakness in the authorization logic that was fixed as part of the overall security improvements. During exploitation, a profiler would likely show getProject being called, which in turn calls the vulnerable _filterProjectPermission.