https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 10:33:28 +0000 https://vulnerability.circl.lu/vuln/ghsa-rpmf-866q-6p89 <p><strong>Affected:</strong> npm: basic-ftp</p> <p>## Summary</p> <p>`basic-ftp` is vulnerable to client-side denial of service when parsing FTP control-channel multiline responses.</p> <p>A malicious or compromised FTP server can send an unterminated multiline response during the initial FTP banner phase, before authentication. The client keeps appending attacker-controlled data into `FtpContext._partialResponse` and repeatedly reparses the accumulated buffer without enforcing a maximum control response size.</p> <p>As a result, an application using `basic-ftp` can remain stuck in `connect()` while memory and CPU usage grow under attacker-controlled input. This can lead to process-level denial of service, container OOM kills, worker restarts, queue backlog, or service degradation in applications that automatically connect to FTP endpoints.</p> <p>---</p> <p>## Details</p> <p>### Root cause</p> <p>The root cause is that incomplete FTP multiline control responses are buffered without an upper bound.</p> <p>`FtpContext` stores incomplete control-channel data in `_partialResponse`:</p> <p>https://github.com/patrickjuchli/basic-ftp/blob/50827c73ca6c1d786c97276e47be8a33d0f2277d/src/FtpContext.ts#L63-L64</p> <p>Incoming control-channel data is handled in `_onControlSocketData`. The implementation concatenates the previous incomplete response with the new chunk, parses the entire accumulated string, and stores `parsed.rest` back into `_partialResponse`:</p> <p>https://github.com/patrickjuchli/basic-ftp/blob/50827c73ca6c1d786c97276e47be8a33d0f2277d/src/FtpContext.ts#L328-L340</p> <p>The relevant flo…</p> <p><strong>Affected:</strong> npm: basic-ftp</p> <p>## Summary</p> <p>`basic-ftp` is vulnerable to client-side denial of service when parsing FTP control-channel multiline responses.</p> <p>A malicious or compromised FTP server can send an unterminated multiline response during the initial FTP banner phase, before authentication. The client keeps appending attacker-controlled data into `FtpContext._partialResponse` and repeatedly reparses the accumulated buffer without enforcing a maximum control response size.</p> <p>As a result, an application using `basic-ftp` can remain stuck in `connect()` while memory and CPU usage grow under attacker-controlled input. This can lead to process-level denial of service, container OOM kills, worker restarts, queue backlog, or service degradation in applications that automatically connect to FTP endpoints.</p> <p>---</p> <p>## Details</p> <p>### Root cause</p> <p>The root cause is that incomplete FTP multiline control responses are buffered without an upper bound.</p> <p>`FtpContext` stores incomplete control-channel data in `_partialResponse`:</p> <p>https://github.com/patrickjuchli/basic-ftp/blob/50827c73ca6c1d786c97276e47be8a33d0f2277d/src/FtpContext.ts#L63-L64</p> <p>Incoming control-channel data is handled in `_onControlSocketData`. The implementation concatenates the previous incomplete response with the new chunk, parses the entire accumulated string, and stores `parsed.rest` back into `_partialResponse`:</p> <p>https://github.com/patrickjuchli/basic-ftp/blob/50827c73ca6c1d786c97276e47be8a33d0f2277d/src/FtpContext.ts#L328-L340</p> <p>The relevant flo…</p> https://vulnerability.circl.lu/vuln/ghsa-rpmf-866q-6p89