受影响的工作区
后端 (backend/)
版本
v2.3.4
部署方式
Docker (docker-compose.yml)
复现步骤
-
Use BiliNote v2.3.4 with the current backend dependency set. The backend installs requests==2.32.3.
-
Configure an isolated test netrc file with a fake canary credential. Do not use real credentials.
-
Trigger the Douyin URL download workflow with a URL shape that exercises CVE-2024-47081 / GHSA-9hjg-9r4m-mvj7.
-
Observe that the backend sends the fake netrc canary credential in an Authorization header.
-
Repeat the same test with only requests overlaid to 2.32.4.
-
Observe that the fake netrc canary is no longer sent.
期望行为
BiliNote should not install a requests version affected by CVE-2024-47081 / GHSA-9hjg-9r4m-mvj7.
The backend should use requests>=2.32.4, so netrc credentials are not looked up from URL userinfo and leaked to the wrong
destination.
实际行为
BiliNote v2.3.4 currently installs requests==2.32.3 through backend/requirements.txt.
In my test, the Douyin URL workflow reached the vulnerable requests path and sent the fake netrc canary credential as an
Authorization header. The same workflow did not leak the canary when requests was overlaid to 2.32.4.
I also checked the Docker path. The published image ghcr.io/jefferyhcool/bilinote:latest reports revision
095d772c7d0f2f4ba1e65c36b7ceb1e2db34723d, version 2.3.4, and has requests==2.32.3. A local backend Docker image built
from backend/Dockerfile also installed requests==2.32.3.
运行环境
- BiliNote: v2.3.4
- Deployment: Docker (docker-compose.yml)
- Image checked: ghcr.io/jefferyhcool/bilinote:latest
- Commit: 095d772
- Affected dependency: requests==2.32.3
- Fixed dependency tested: requests==2.32.4
日志 / 堆栈
Relevant dependency state:
backend/requirements.txt installs requests==2.32.3
ghcr.io/jefferyhcool/bilinote:latest has requests==2.32.3
local backend Docker build has requests==2.32.3
Observed test result with current dependency:
BiliNote Douyin URL workflow reached requests
fake netrc canary was sent in Authorization header
Control with only requests changed to 2.32.4:
BiliNote Douyin URL workflow reached requests
fake netrc canary was not sent
This maps to CVE-2024-47081 / GHSA-9hjg-9r4m-mvj7, fixed in requests 2.32.4.
Suggested fix:
requests>=2.32.4
提交前自查
受影响的工作区
后端 (backend/)
版本
v2.3.4
部署方式
Docker (docker-compose.yml)
复现步骤
Use BiliNote v2.3.4 with the current backend dependency set. The backend installs
requests==2.32.3.Configure an isolated test netrc file with a fake canary credential. Do not use real credentials.
Trigger the Douyin URL download workflow with a URL shape that exercises CVE-2024-47081 / GHSA-9hjg-9r4m-mvj7.
Observe that the backend sends the fake netrc canary credential in an
Authorizationheader.Repeat the same test with only
requestsoverlaid to2.32.4.Observe that the fake netrc canary is no longer sent.
期望行为
BiliNote should not install a requests version affected by CVE-2024-47081 / GHSA-9hjg-9r4m-mvj7.
The backend should use
requests>=2.32.4, so netrc credentials are not looked up from URL userinfo and leaked to the wrongdestination.
实际行为
BiliNote v2.3.4 currently installs
requests==2.32.3throughbackend/requirements.txt.In my test, the Douyin URL workflow reached the vulnerable requests path and sent the fake netrc canary credential as an
Authorizationheader. The same workflow did not leak the canary when requests was overlaid to2.32.4.I also checked the Docker path. The published image
ghcr.io/jefferyhcool/bilinote:latestreports revision095d772c7d0f2f4ba1e65c36b7ceb1e2db34723d, version2.3.4, and hasrequests==2.32.3. A local backend Docker image builtfrom
backend/Dockerfilealso installedrequests==2.32.3.运行环境
日志 / 堆栈
提交前自查