CWE-476
AllowedNULL Pointer Dereference
Abstraction: Base · Status: Stable
The product dereferences a pointer that it expects to be valid but is NULL.
6325 vulnerabilities reference this CWE, most recent first.
GHSA-RXRQ-FX2P-JJC3
Vulnerability from github – Published: 2025-11-07 18:30 – Updated: 2025-11-14 21:30A NULL pointer dereference vulnerability has been reported to affect several product versions. If a remote attacker gains a user account, they can then exploit the vulnerability to launch a denial-of-service (DoS) attack.
We have already fixed the vulnerability in the following version: File Station 5 5.5.6.5018 and later
{
"affected": [],
"aliases": [
"CVE-2025-47207"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-11-07T16:15:38Z",
"severity": "MODERATE"
},
"details": "A NULL pointer dereference vulnerability has been reported to affect several product versions. If a remote attacker gains a user account, they can then exploit the vulnerability to launch a denial-of-service (DoS) attack.\n\nWe have already fixed the vulnerability in the following version:\nFile Station 5 5.5.6.5018 and later",
"id": "GHSA-rxrq-fx2p-jjc3",
"modified": "2025-11-14T21:30:28Z",
"published": "2025-11-07T18:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-47207"
},
{
"type": "WEB",
"url": "https://www.qnap.com/en/security-advisory/qsa-25-38"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-RXRV-JJF7-PH47
Vulnerability from github – Published: 2025-03-14 00:30 – Updated: 2025-03-14 00:30In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum: Guard against invalid local ports
When processing events generated by the device's firmware, the driver protects itself from events reported for non-existent local ports, but not for the CPU port (local port 0), which exists, but does not have all the fields as any local port.
This can result in a NULL pointer dereference when trying access 'struct mlxsw_sp_port' fields which are not initialized for CPU port.
Commit 63b08b1f6834 ("mlxsw: spectrum: Protect driver from buggy firmware") already handled such issue by bailing early when processing a PUDE event reported for the CPU port.
Generalize the approach by moving the check to a common function and making use of it in all relevant places.
{
"affected": [],
"aliases": [
"CVE-2022-49134"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:00:50Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmlxsw: spectrum: Guard against invalid local ports\n\nWhen processing events generated by the device\u0027s firmware, the driver\nprotects itself from events reported for non-existent local ports, but\nnot for the CPU port (local port 0), which exists, but does not have all\nthe fields as any local port.\n\nThis can result in a NULL pointer dereference when trying access\n\u0027struct mlxsw_sp_port\u0027 fields which are not initialized for CPU port.\n\nCommit 63b08b1f6834 (\"mlxsw: spectrum: Protect driver from buggy firmware\")\nalready handled such issue by bailing early when processing a PUDE event\nreported for the CPU port.\n\nGeneralize the approach by moving the check to a common function and\nmaking use of it in all relevant places.",
"id": "GHSA-rxrv-jjf7-ph47",
"modified": "2025-03-14T00:30:50Z",
"published": "2025-03-14T00:30:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49134"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4cad27ba2e5a5843a7fab5aa30de2b8e8c3db3a8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bcdfd615f83b4bd04678109bf18022d1476e4bbf"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-RXVG-52XH-5PV7
Vulnerability from github – Published: 2024-09-18 09:30 – Updated: 2024-11-20 18:32In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Run DC_LOG_DC after checking link->link_enc
[WHAT] The DC_LOG_DC should be run after link->link_enc is checked, not before.
This fixes 1 REVERSE_INULL issue reported by Coverity.
{
"affected": [],
"aliases": [
"CVE-2024-46776"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-18T08:15:05Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Run DC_LOG_DC after checking link-\u003elink_enc\n\n[WHAT]\nThe DC_LOG_DC should be run after link-\u003elink_enc is checked, not before.\n\nThis fixes 1 REVERSE_INULL issue reported by Coverity.",
"id": "GHSA-rxvg-52xh-5pv7",
"modified": "2024-11-20T18:32:15Z",
"published": "2024-09-18T09:30:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46776"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3a82f62b0d9d7687eac47603bb6cd14a50fa718b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/874e3bb302f97b94ac548959ec4f925b8e7b45e2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/adc74d25cdbba978afbb57caec23bbcd0329f7b8"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-V22F-RW8M-47VR
Vulnerability from github – Published: 2024-06-21 12:31 – Updated: 2025-09-17 18:31In the Linux kernel, the following vulnerability has been resolved:
greybus: lights: check return of get_channel_from_mode
If channel for the given node is not found we return null from get_channel_from_mode. Make sure we validate the return pointer before using it in two of the missing places.
This was originally reported in [0]: Found by Linux Verification Center (linuxtesting.org) with SVACE.
[0] https://lore.kernel.org/all/20240301190425.120605-1-m.lobanov@rosalinux.ru
{
"affected": [],
"aliases": [
"CVE-2024-38637"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-21T11:15:12Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ngreybus: lights: check return of get_channel_from_mode\n\nIf channel for the given node is not found we return null from\nget_channel_from_mode. Make sure we validate the return pointer\nbefore using it in two of the missing places.\n\nThis was originally reported in [0]:\nFound by Linux Verification Center (linuxtesting.org) with SVACE.\n\n[0] https://lore.kernel.org/all/20240301190425.120605-1-m.lobanov@rosalinux.ru",
"id": "GHSA-v22f-rw8m-47vr",
"modified": "2025-09-17T18:31:14Z",
"published": "2024-06-21T12:31:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38637"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/330f6bcdcef03f70f81db5f2ed6747af656a09f2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/518e2c46b5dbce40b1aa0100001d03c3ceaa7d38"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/895cdd9aa9546523df839f9cc1488a0ecc1e0731"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8f4a76d477f0cc3c54d512f07f6f88c8e1c1e07b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9b41a9b9c8be8c552f10633453fdb509e83b66f8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a1ba19a1ae7cd1e324685ded4ab563e78fe68648"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e2c64246e5dc8c0d35ec41770b85e2b4cafdff21"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/eac10cf3a97ffd4b4deb0a29f57c118225a42850"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-V22H-74VW-3J73
Vulnerability from github – Published: 2026-05-19 06:30 – Updated: 2026-05-19 06:30NULL pointer dereference vulnerability in Samsung Open Source Walrus allows Pointer Manipulation.
This issue affects Walrus: f339b8ee4ea701772e8ae640b3d1b12ac02b1ae9.
{
"affected": [],
"aliases": [
"CVE-2026-47308"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-19T05:16:25Z",
"severity": "MODERATE"
},
"details": "NULL pointer dereference vulnerability in Samsung Open Source Walrus allows Pointer Manipulation.\n\nThis issue affects Walrus: f339b8ee4ea701772e8ae640b3d1b12ac02b1ae9.",
"id": "GHSA-v22h-74vw-3j73",
"modified": "2026-05-19T06:30:30Z",
"published": "2026-05-19T06:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-47308"
},
{
"type": "WEB",
"url": "https://github.com/Samsung/walrus/pull/409"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-V22X-X62X-Q5QJ
Vulnerability from github – Published: 2024-02-13 18:38 – Updated: 2024-02-13 18:38Windows Lightweight Directory Access Protocol (LDAP) Denial of Service Vulnerability
{
"affected": [],
"aliases": [
"CVE-2024-21356"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-02-13T18:15:52Z",
"severity": "MODERATE"
},
"details": "Windows Lightweight Directory Access Protocol (LDAP) Denial of Service Vulnerability",
"id": "GHSA-v22x-x62x-q5qj",
"modified": "2024-02-13T18:38:23Z",
"published": "2024-02-13T18:38:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-21356"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-21356"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-V237-VCGW-685X
Vulnerability from github – Published: 2022-05-14 03:52 – Updated: 2025-04-20 03:46read_formatted_entries in dwarf2.c in the Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.29, does not properly validate the format count, which allows remote attackers to cause a denial of service (NULL pointer dereference and application crash) via a crafted ELF file, related to concat_filename.
{
"affected": [],
"aliases": [
"CVE-2017-15023"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-10-05T01:29:00Z",
"severity": "MODERATE"
},
"details": "read_formatted_entries in dwarf2.c in the Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.29, does not properly validate the format count, which allows remote attackers to cause a denial of service (NULL pointer dereference and application crash) via a crafted ELF file, related to concat_filename.",
"id": "GHSA-v237-vcgw-685x",
"modified": "2025-04-20T03:46:20Z",
"published": "2022-05-14T03:52:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-15023"
},
{
"type": "WEB",
"url": "https://blogs.gentoo.org/ago/2017/10/03/binutils-null-pointer-dereference-in-concat_filename-dwarf2-c"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/201801-01"
},
{
"type": "WEB",
"url": "https://sourceware.org/bugzilla/show_bug.cgi?id=22200"
},
{
"type": "WEB",
"url": "https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git%3Bh=c361faae8d964db951b7100cada4dcdc983df1bf"
},
{
"type": "WEB",
"url": "https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=c361faae8d964db951b7100cada4dcdc983df1bf"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/101611"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-V25M-V785-G666
Vulnerability from github – Published: 2025-07-09 03:30 – Updated: 2025-07-09 03:30A vulnerability has been found in 9fans plan9port up to 9da5b44 and classified as problematic. Affected by this vulnerability is the function value_decode in the library src/libsec/port/x509.c. The manipulation leads to null pointer dereference. Local access is required to approach this attack. The exploit has been disclosed to the public and may be used. This product takes the approach of rolling releases to provide continious delivery. Therefore, version details for affected and updated releases are not available. The identifier of the patch is deae8939583d83fd798fca97665e0e94656c3ee8. It is recommended to apply a patch to fix this issue.
{
"affected": [],
"aliases": [
"CVE-2025-7209"
],
"database_specific": {
"cwe_ids": [
"CWE-404",
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-09T01:15:50Z",
"severity": "MODERATE"
},
"details": "A vulnerability has been found in 9fans plan9port up to 9da5b44 and classified as problematic. Affected by this vulnerability is the function value_decode in the library src/libsec/port/x509.c. The manipulation leads to null pointer dereference. Local access is required to approach this attack. The exploit has been disclosed to the public and may be used. This product takes the approach of rolling releases to provide continious delivery. Therefore, version details for affected and updated releases are not available. The identifier of the patch is deae8939583d83fd798fca97665e0e94656c3ee8. It is recommended to apply a patch to fix this issue.",
"id": "GHSA-v25m-v785-g666",
"modified": "2025-07-09T03:30:23Z",
"published": "2025-07-09T03:30:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-7209"
},
{
"type": "WEB",
"url": "https://github.com/9fans/plan9port/issues/711"
},
{
"type": "WEB",
"url": "https://github.com/9fans/plan9port/issues/711#issuecomment-2819905220"
},
{
"type": "WEB",
"url": "https://git.9front.org/plan9front/plan9front/deae8939583d83fd798fca97665e0e94656c3ee8/commit.html"
},
{
"type": "WEB",
"url": "https://github.com/user-attachments/files/19698361/plan9port_crash_2.txt"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.315157"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.315157"
},
{
"type": "WEB",
"url": "https://vuldb.com/?submit.607685"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-V285-5C63-6RPH
Vulnerability from github – Published: 2024-11-12 18:30 – Updated: 2024-11-12 18:30A null pointer dereference in Ivanti Avalanche before 6.4.6 allows a remote unauthenticated attacker to cause a denial of service.
{
"affected": [],
"aliases": [
"CVE-2024-50318"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-12T16:15:23Z",
"severity": "HIGH"
},
"details": "A null pointer dereference in Ivanti Avalanche before 6.4.6 allows a remote unauthenticated attacker to cause a denial of service.",
"id": "GHSA-v285-5c63-6rph",
"modified": "2024-11-12T18:30:56Z",
"published": "2024-11-12T18:30:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50318"
},
{
"type": "WEB",
"url": "https://forums.ivanti.com/s/article/Security-Advisory-Ivanti-Avalanche-Multiple-CVEs-Q4-2024-Release"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-V2CH-C8V8-FGR7
Vulnerability from github – Published: 2025-08-29 16:24 – Updated: 2025-08-29 16:24Sending AWS chunk data with no Content-Length HTTP header causes the panic, every time.
Reproduction
Setup versity server running on port 7071, no SSL (for ease of packet tracing with tshark). Problem can be reproduced with or without SSL on the versity end.
Use nginx to reverse proxy on port 7070. This does have to be SSL enabled for the repro to occur. nginx config:
upstream tony_versity {
server 127.0.0.1:7071;
keepalive 15;
}
server {
listen 7070 ssl ;
access_log /var/log/nginx/tony_versity_proxy.access.log;
error_log /var/log/nginx/tony_versity_proxy.error.log;
# Allow any size file to be uploaded.
client_max_body_size 0;
# Allow special characters in headers
ignore_invalid_headers off;
# Disable buffering
proxy_buffering off;
proxy_request_buffering off;
# Load configuration files for the default server block.
include /etc/nginx/default.d/*.conf;
ssl_certificate "/WS/TEMP/lh.crt";
ssl_certificate_key "/WS/TEMP/lh.key";
ssl_session_cache shared:SSL:1m;
ssl_session_timeout 10m;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;
ssl_protocols TLSv1.2 TLSv1.3;
location / {
allow all;
proxy_pass http://127.0.0.1:7071;
proxy_http_version 1.1;
proxy_read_timeout 120;
proxy_connect_timeout 300;
# Set headers
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Transfer-Encoding "";
# CORS headers
add_header 'Access-Control-Allow-Origin' '*' always;
add_header 'Access-Control-Allow-Credentials' 'true' always;
add_header 'Access-Control-Allow-Headers' 'Authorization,Accept,ETag,Origin,DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Content-Range,Range' always;
add_header 'Access-Control-Allow-Methods' 'GET,POST,OPTIONS,PUT,DELETE,PATCH' always;
add_header 'Access-Control-Expose-Headers' 'ETag, Content-Length, Content-Range' always;
# Optional security headers
add_header X-Content-Type-Options nosniff always;
add_header X-Frame-Options DENY always;
add_header Referrer-Policy no-referrer always;
# Preflight (OPTIONS) handler
if ($request_method = OPTIONS) {
add_header Access-Control-Allow-Origin '*' always;
add_header Access-Control-Allow-Methods 'GET, POST, OPTIONS, PUT, DELETE, PATCH' always;
add_header Access-Control-Allow-Headers 'Authorization,Accept,ETag,Origin,DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Content-Range,Range' always;
add_header Access-Control-Expose-Headers 'ETag, Content-Length, Content-Range' always;
add_header Content-Type text/plain;
add_header Content-Length 0;
return 204;
}
}
}
Use aws s3 cp to copy a large file (one that will trigger multipart upload) into versity via the nginx proxy on port 7070. AWS CLI must be version 2 for the repro to occur. Connecting directly to versity on port 7070 does not trigger the repro.
Initial crash analysis
The versity server enters a panic exception in function HashReader (csum-reader.go). The panic is due to a null value in the field r which should be a pointer to an io.Reader.
The reason this field is blank goes back to code in the fasthttp library, ContinueReadBodyStream. This function exits prematurely if the incoming request ContentLength field is set to -2, and therefore does not set up an io.Reader in the request context structure.
-2 is not a valid content-length for an HTTP message, it is a special value used internally by the fasthttp module. (Unfortunately the author hard coded the value rather than using a meaningful macro, which would have aided the understanding here. )
The reason for the -2 can be found in function parseHeaders(headers.go in fasthttp). The header struct content length is set to -2 at the start of the function, and will be overwritten if an HTTP content-length header is encountered during the parsing. If no such header is present in the request, it stays as -2 with the later result of skipping the creation of an io.Reader. Seems reasonable - no content, no need for a reader? (Note that the presence of content-length triggers body reader creation even if the value is 0.) The fasthttp code replaces the illegal -2 value with 0 before passing the request up to Versity.
So the pathway of this crash is receiving a request with no content-length, which means no body reader is set in the request context structure, but Versity tries to read anyway in the hash routines.
This pathology was confirmed by artificially creating a content-length on all incoming packets that didn’t have one, the outcome being that this panic did not occur, although the overall upload still reported failure (I didn’t go into exactly why as the point had been proven).
Further Analysis
The question becomes why there is no HTTP content-length header in this request. The answer to this is that the large transfer is being done using AWS chunking. Wireshark shows the packet structure. There is an initial POST request with content-length zero: Hypertext Transfer Protocol
POST /ttt/f2?uploads HTTP/1.1\r\n
Host: 127.0.0.1:7070\r\n
X-Real-IP: 127.0.0.1\r\n
X-Forwarded-For: 127.0.0.1\r\n
X-Forwarded-Proto: https\r\n
Connection: close\r\n
Content-Length: 0\r\n
Accept-Encoding: identity\r\n
x-amz-checksum-algorithm: CRC64NVME\r\n
[truncated]User-Agent: aws-cli/2.27.52 md/awscrt#0.26.1 ua/2.1 os/linux#4.18.0-553.16.1.el8_10.x86_64 md/arch#x86_64 lang/python#3.13.4 md/pyimpl#CPython m/E,Z,N,G,b cfg/retry-mode#standard md/installer#exe md/distrib#rhel.8 md/prompt#off
X-Amz-Date: 20250718T105915Z\r\n
X-Amz-Content-SHA256: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855\r\n
[truncated]Authorization: AWS4-HMAC-SHA256 Credential=AKIA000000000000000/20250718/us-east-1/s3/aws4_request, SignedHeaders=host;x-amz-checksum-algorithm;x-amz-content-sha256;x-amz-date, Signature=cd9f6a85ae2dd964aa44274d7d0642c51f8b32584
\r\n
[Full request URI: http://127.0.0.1:7070/ttt/f2?uploads]
[HTTP request 1/1]
[Response in frame: 6]
.. followed soon after by a PUT request with ‘content-encdoding: aws-chunked’. According to the AWS documentation, this encoding is used when the size of the upload is not known in advance, and a content-length header is expressly forbidden. AWS supplies other headers with size information, but these are not recognised by fasthttp. Hypertext Transfer Protocol
PUT /ttt/f2?uploadId=7170abfd-e29a-40fe-bd34-31b434cc1b6b&partNumber=1 HTTP/1.1\r\n
Host: 127.0.0.1:7070\r\n
X-Real-IP: 127.0.0.1\r\n
X-Forwarded-For: 127.0.0.1\r\n
X-Forwarded-Proto: https\r\n
Connection: close\r\n
Accept-Encoding: identity\r\n
x-amz-sdk-checksum-algorithm: CRC64NVME\r\n
[truncated]User-Agent: aws-cli/2.27.52 md/awscrt#0.26.1 ua/2.1 os/linux#4.18.0-553.16.1.el8_10.x86_64 md/arch#x86_64 lang/python#3.13.4 md/pyimpl#CPython m/E,Z,N,G,b,W cfg/retry-mode#standard md/installer#exe md/distrib#rhel.8 md/prompt#o
Content-Encoding: aws-chunked\r\n
X-Amz-Trailer: x-amz-checksum-crc64nvme\r\n
X-Amz-Decoded-Content-Length: 8388608\r\n
X-Amz-Date: 20250718T105915Z\r\n
X-Amz-Content-SHA256: STREAMING-UNSIGNED-PAYLOAD-TRAILER\r\n
[truncated]Authorization: AWS4-HMAC-SHA256 Credential=AKIA000000000000000/20250718/us-east-1/s3/aws4_request, SignedHeaders=content-encoding;host;x-amz-content-sha256;x-amz-date;x-amz-decoded-content-length;x-amz-sdk-checksum-algorithm;x-
\r\n
[Full request URI: http://127.0.0.1:7070/ttt/f2?uploadId=7170abfd-e29a-40fe-bd34-31b434cc1b6b&partNumber=1]
[HTTP request 1/1]
The initial response to the first POST request appears to be identical in both the direct and via nginx traces: DIRECT: Hypertext Transfer Protocol
HTTP/1.1 200 OK\r\n
Server: VERSITYGW\r\n
Date: Fri, 18 Jul 2025 11:01:02 GMT\r\n
Content-Type: application/xml\r\n
Content-Length: 240\r\n
X-Amz-Checksum-Algorithm: CRC64NVME\r\n
Connection: close\r\n
\r\n
[HTTP response 1/1]
[Time since request: 0.024200152 seconds]
[Request in frame: 4]
[Request URI: http://127.0.0.1:7071/ttt/f2?uploads]
File Data: 240 bytes
VIA NGINX PROXY: Hypertext Transfer Protocol
HTTP/1.1 200 OK\r\n
Server: VERSITYGW\r\n
Date: Fri, 18 Jul 2025 10:59:15 GMT\r\n
Content-Type: application/xml\r\n
Content-Length: 240\r\n
X-Amz-Checksum-Algorithm: CRC64NVME\r\n
Connection: close\r\n
\r\n
[HTTP response 1/1]
[Time since request: 0.024228406 seconds]
[Request in frame: 4]
[Request URI: http://127.0.0.1:7070/ttt/f2?uploads]
File Data: 240 bytes
What is yet to know
Wireshark traces show that the exact same AWS command results in a different upload pattern when connecting directly to Versity (with or without SSL) rather than going through nginx. There is a similar initial POST but followed by a stream of raw TCP with ‘100 - Continue’ responses from the server. There is no PUT request with content-encoding aws-chunked: Hypertext Transfer Protocol
POST /ttt/f2?uploads HTTP/1.1\r\n
Host: 127.0.0.1:7071\r\n
Accept-Encoding: identity\r\n
x-amz-checksum-algorithm: CRC64NVME\r\n
[truncated]User-Agent: aws-cli/2.27.52 md/awscrt#0.26.1 ua/2.1 os/linux#4.18.0-553.16.1.el8_10.x86_64 md/arch#x86_64 lang/python#3.13.4 md/pyimpl#CPython m/b,G,Z,N,E cfg/retry-mode#standard md/installer#exe md/distrib#rhel.8 md/prompt#off
X-Amz-Date: 20250718T110102Z\r\n
X-Amz-Content-SHA256: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855\r\n
[truncated]Authorization: AWS4-HMAC-SHA256 Credential=AKIA000000000000000/20250718/us-east-1/s3/aws4_request, SignedHeaders=host;x-amz-checksum-algorithm;x-amz-content-sha256;x-amz-date, Signature=925d2f18f7f88ab7826ae7faf61f95b17033f5e19
Content-Length: 0\r\n
\r\n
[Full request URI: http://127.0.0.1:7071/ttt/f2?uploads]
[HTTP request 1/1]
[Response in frame: 6]
It is unclear why AWS switches to the chunked mode when connecting through nginx. It is possible that changes to the nginx config could work around this, however the Versity behaviour remains a problem. At the very least this is a potential DDOS vulnerability. There is no structured exception handling in Versity at all and no defensive coding such as verifying callbacks are non-null before attempting to use them.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/versity/versitygw"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.0.17"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": true,
"github_reviewed_at": "2025-08-29T16:24:12Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "Sending AWS chunk data with no Content-Length HTTP header causes the panic, every time. \n\n### Reproduction\n\nSetup versity server running on port 7071, no SSL (for ease of packet tracing with tshark). Problem can be reproduced with or without SSL on the versity end. \n\nUse nginx to reverse proxy on port 7070. This does have to be SSL enabled for the repro to occur. nginx config: \n\n```\nupstream tony_versity {\n server 127.0.0.1:7071;\n keepalive 15;\n}\n\nserver {\n listen 7070 ssl ;\n access_log /var/log/nginx/tony_versity_proxy.access.log;\n error_log /var/log/nginx/tony_versity_proxy.error.log;\n\n # Allow any size file to be uploaded.\n client_max_body_size 0;\n # Allow special characters in headers\n ignore_invalid_headers off;\n # Disable buffering\n proxy_buffering off;\n proxy_request_buffering off;\n\n # Load configuration files for the default server block.\n include /etc/nginx/default.d/*.conf;\n\n ssl_certificate \"/WS/TEMP/lh.crt\";\n ssl_certificate_key \"/WS/TEMP/lh.key\";\n ssl_session_cache shared:SSL:1m;\n ssl_session_timeout 10m;\n ssl_ciphers HIGH:!aNULL:!MD5;\n ssl_prefer_server_ciphers on;\n ssl_protocols TLSv1.2 TLSv1.3;\n\n location / {\n allow all;\n proxy_pass http://127.0.0.1:7071;\n proxy_http_version 1.1;\n proxy_read_timeout 120;\n proxy_connect_timeout 300;\n\n # Set headers\n proxy_set_header Host $http_host;\n proxy_set_header X-Real-IP $remote_addr;\n proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;\n proxy_set_header X-Forwarded-Proto $scheme;\n proxy_set_header Transfer-Encoding \"\";\n\n # CORS headers\n add_header \u0027Access-Control-Allow-Origin\u0027 \u0027*\u0027 always;\n add_header \u0027Access-Control-Allow-Credentials\u0027 \u0027true\u0027 always;\n add_header \u0027Access-Control-Allow-Headers\u0027 \u0027Authorization,Accept,ETag,Origin,DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Content-Range,Range\u0027 always;\n add_header \u0027Access-Control-Allow-Methods\u0027 \u0027GET,POST,OPTIONS,PUT,DELETE,PATCH\u0027 always;\n add_header \u0027Access-Control-Expose-Headers\u0027 \u0027ETag, Content-Length, Content-Range\u0027 always;\n\n # Optional security headers\n add_header X-Content-Type-Options nosniff always;\n add_header X-Frame-Options DENY always;\n add_header Referrer-Policy no-referrer always;\n\n # Preflight (OPTIONS) handler\n if ($request_method = OPTIONS) {\n add_header Access-Control-Allow-Origin \u0027*\u0027 always;\n add_header Access-Control-Allow-Methods \u0027GET, POST, OPTIONS, PUT, DELETE, PATCH\u0027 always;\n add_header Access-Control-Allow-Headers \u0027Authorization,Accept,ETag,Origin,DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Content-Range,Range\u0027 always;\n add_header Access-Control-Expose-Headers \u0027ETag, Content-Length, Content-Range\u0027 always;\n add_header Content-Type text/plain;\n add_header Content-Length 0;\n return 204;\n }\n }\n}\n```\n\nUse aws s3 cp to copy a large file (one that will trigger multipart upload) into versity via the nginx proxy on port 7070. AWS CLI must be version 2 for the repro to occur. Connecting directly to versity on port 7070 does not trigger the repro.\n\n \n### Initial crash analysis\n\nThe versity server enters a panic exception in function `HashReader` (csum-reader.go). The panic is due to a null value in the field r which should be a pointer to an io.Reader. \n\nThe reason this field is blank goes back to code in the `fasthttp` library, `ContinueReadBodyStream`. This function exits prematurely if the incoming request `ContentLength` field is set to `-2`, and therefore does not set up an io.Reader in the request context structure. \n\n`-2` is not a valid content-length for an HTTP message, it is a special value used internally by the `fasthttp` module. (Unfortunately the author hard coded the value rather than using a meaningful macro, which would have aided the understanding here. )\n\nThe reason for the `-2` can be found in function `parseHeaders`(headers.go in fasthttp). The header struct content length is set to `-2` at the start of the function, and will be overwritten if an HTTP content-length header is encountered during the parsing. If no such header is present in the request, it stays as `-2` with the later result of skipping the creation of an io.Reader. Seems reasonable - no content, no need for a reader? (Note that the presence of content-length triggers body reader creation even if the value is 0.) The fasthttp code replaces the illegal `-2` value with `0` before passing the request up to Versity. \n\nSo the pathway of this crash is receiving a request with no content-length, which means no body reader is set in the request context structure, but Versity tries to read anyway in the hash routines. \n\nThis pathology was confirmed by artificially creating a content-length on all incoming packets that didn\u2019t have one, the outcome being that this panic did not occur, although the overall upload still reported failure (I didn\u2019t go into exactly why as the point had been proven).\n\n \n### Further Analysis\n\nThe question becomes why there is no HTTP content-length header in this request. The answer to this is that the large transfer is being done using AWS chunking. Wireshark shows the packet structure. There is an initial POST request with content-length zero:\nHypertext Transfer Protocol\n```\n POST /ttt/f2?uploads HTTP/1.1\\r\\n\n Host: 127.0.0.1:7070\\r\\n\n X-Real-IP: 127.0.0.1\\r\\n\n X-Forwarded-For: 127.0.0.1\\r\\n\n X-Forwarded-Proto: https\\r\\n\n Connection: close\\r\\n\n Content-Length: 0\\r\\n\n Accept-Encoding: identity\\r\\n\n x-amz-checksum-algorithm: CRC64NVME\\r\\n\n [truncated]User-Agent: aws-cli/2.27.52 md/awscrt#0.26.1 ua/2.1 os/linux#4.18.0-553.16.1.el8_10.x86_64 md/arch#x86_64 lang/python#3.13.4 md/pyimpl#CPython m/E,Z,N,G,b cfg/retry-mode#standard md/installer#exe md/distrib#rhel.8 md/prompt#off\n X-Amz-Date: 20250718T105915Z\\r\\n\n X-Amz-Content-SHA256: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855\\r\\n\n [truncated]Authorization: AWS4-HMAC-SHA256 Credential=AKIA000000000000000/20250718/us-east-1/s3/aws4_request, SignedHeaders=host;x-amz-checksum-algorithm;x-amz-content-sha256;x-amz-date, Signature=cd9f6a85ae2dd964aa44274d7d0642c51f8b32584\n \\r\\n\n [Full request URI: http://127.0.0.1:7070/ttt/f2?uploads]\n [HTTP request 1/1]\n [Response in frame: 6]\n```\n.. followed soon after by a PUT request with \u2018content-encdoding: aws-chunked\u2019. According to the AWS documentation, this encoding is used when the size of the upload is not known in advance, and a content-length header is expressly forbidden. AWS supplies other headers with size information, but these are not recognised by fasthttp.\nHypertext Transfer Protocol\n```\n PUT /ttt/f2?uploadId=7170abfd-e29a-40fe-bd34-31b434cc1b6b\u0026partNumber=1 HTTP/1.1\\r\\n\n Host: 127.0.0.1:7070\\r\\n\n X-Real-IP: 127.0.0.1\\r\\n\n X-Forwarded-For: 127.0.0.1\\r\\n\n X-Forwarded-Proto: https\\r\\n\n Connection: close\\r\\n\n Accept-Encoding: identity\\r\\n\n x-amz-sdk-checksum-algorithm: CRC64NVME\\r\\n\n [truncated]User-Agent: aws-cli/2.27.52 md/awscrt#0.26.1 ua/2.1 os/linux#4.18.0-553.16.1.el8_10.x86_64 md/arch#x86_64 lang/python#3.13.4 md/pyimpl#CPython m/E,Z,N,G,b,W cfg/retry-mode#standard md/installer#exe md/distrib#rhel.8 md/prompt#o\n Content-Encoding: aws-chunked\\r\\n\n X-Amz-Trailer: x-amz-checksum-crc64nvme\\r\\n\n X-Amz-Decoded-Content-Length: 8388608\\r\\n\n X-Amz-Date: 20250718T105915Z\\r\\n\n X-Amz-Content-SHA256: STREAMING-UNSIGNED-PAYLOAD-TRAILER\\r\\n\n [truncated]Authorization: AWS4-HMAC-SHA256 Credential=AKIA000000000000000/20250718/us-east-1/s3/aws4_request, SignedHeaders=content-encoding;host;x-amz-content-sha256;x-amz-date;x-amz-decoded-content-length;x-amz-sdk-checksum-algorithm;x-\n \\r\\n\n [Full request URI: http://127.0.0.1:7070/ttt/f2?uploadId=7170abfd-e29a-40fe-bd34-31b434cc1b6b\u0026partNumber=1]\n [HTTP request 1/1]\n```\n \n\nThe initial response to the first POST request appears to be identical in both the direct and via nginx traces:\nDIRECT:\nHypertext Transfer Protocol\n```\n HTTP/1.1 200 OK\\r\\n\n Server: VERSITYGW\\r\\n\n Date: Fri, 18 Jul 2025 11:01:02 GMT\\r\\n\n Content-Type: application/xml\\r\\n\n Content-Length: 240\\r\\n\n X-Amz-Checksum-Algorithm: CRC64NVME\\r\\n\n Connection: close\\r\\n\n \\r\\n\n [HTTP response 1/1]\n [Time since request: 0.024200152 seconds]\n [Request in frame: 4]\n [Request URI: http://127.0.0.1:7071/ttt/f2?uploads]\n File Data: 240 bytes\n```\n \nVIA NGINX PROXY:\nHypertext Transfer Protocol\n```\n HTTP/1.1 200 OK\\r\\n\n Server: VERSITYGW\\r\\n\n Date: Fri, 18 Jul 2025 10:59:15 GMT\\r\\n\n Content-Type: application/xml\\r\\n\n Content-Length: 240\\r\\n\n X-Amz-Checksum-Algorithm: CRC64NVME\\r\\n\n Connection: close\\r\\n\n \\r\\n\n [HTTP response 1/1]\n [Time since request: 0.024228406 seconds]\n [Request in frame: 4]\n [Request URI: http://127.0.0.1:7070/ttt/f2?uploads]\n File Data: 240 bytes\n```\n### What is yet to know\n\nWireshark traces show that the exact same AWS command results in a different upload pattern when connecting directly to Versity (with or without SSL) rather than going through nginx. There is a similar initial POST but followed by a stream of raw TCP with \u2018100 - Continue\u2019 responses from the server. There is no PUT request with content-encoding aws-chunked:\nHypertext Transfer Protocol\n```\n POST /ttt/f2?uploads HTTP/1.1\\r\\n\n Host: 127.0.0.1:7071\\r\\n\n Accept-Encoding: identity\\r\\n\n x-amz-checksum-algorithm: CRC64NVME\\r\\n\n [truncated]User-Agent: aws-cli/2.27.52 md/awscrt#0.26.1 ua/2.1 os/linux#4.18.0-553.16.1.el8_10.x86_64 md/arch#x86_64 lang/python#3.13.4 md/pyimpl#CPython m/b,G,Z,N,E cfg/retry-mode#standard md/installer#exe md/distrib#rhel.8 md/prompt#off\n X-Amz-Date: 20250718T110102Z\\r\\n\n X-Amz-Content-SHA256: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855\\r\\n\n [truncated]Authorization: AWS4-HMAC-SHA256 Credential=AKIA000000000000000/20250718/us-east-1/s3/aws4_request, SignedHeaders=host;x-amz-checksum-algorithm;x-amz-content-sha256;x-amz-date, Signature=925d2f18f7f88ab7826ae7faf61f95b17033f5e19\n Content-Length: 0\\r\\n\n \\r\\n\n [Full request URI: http://127.0.0.1:7071/ttt/f2?uploads]\n [HTTP request 1/1]\n [Response in frame: 6]\n```\nIt is unclear why AWS switches to the chunked mode when connecting through nginx. It is possible that changes to the nginx config could work around this, however the Versity behaviour remains a problem. At the very least this is a potential DDOS vulnerability. There is no structured exception handling in Versity at all and no defensive coding such as verifying callbacks are non-null before attempting to use them.",
"id": "GHSA-v2ch-c8v8-fgr7",
"modified": "2025-08-29T16:24:12Z",
"published": "2025-08-29T16:24:12Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/versity/versitygw/security/advisories/GHSA-v2ch-c8v8-fgr7"
},
{
"type": "WEB",
"url": "https://github.com/versity/versitygw/issues/1418"
},
{
"type": "WEB",
"url": "https://github.com/versity/versitygw/commit/0972af078325ab5c6acd37abffe6bea345ac7db0"
},
{
"type": "PACKAGE",
"url": "https://github.com/versity/versitygw"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:P",
"type": "CVSS_V4"
}
],
"summary": "Versity panic induced by AWS chunked data sent to port"
}
Mitigation MIT-56
For any pointers that could have been modified or provided from a function that can return NULL, check the pointer for NULL before use. When working with a multithreaded or otherwise asynchronous environment, ensure that proper locking APIs are used to lock before the check, and unlock when it has finished [REF-1484].
Mitigation
Select a programming language that is not susceptible to these issues.
Mitigation
Check the results of all functions that return a value and verify that the value is non-null before acting upon it.
Mitigation
Identify all variables and data stores that receive information from external sources, and apply input validation to make sure that they are only initialized to expected values.
Mitigation
Explicitly initialize all variables and other data stores, either during declaration or just before the first usage.
No CAPEC attack patterns related to this CWE.