Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
2 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
ChatterBot's UbuntuCorpusTrainer.extract() uses a predictable, home-rooted output directory (~/ubuntudata/ubuntudialogs) with a check-then-create pattern (if not os.path.exists: os.makedirs) followed by tar.extractall(path=self.datapath). A local attacker who pre-plants a symlink at the predictable path causes os.path.exists() to return True (following the symlink), skipping makedirs, and subsequent extractall writes archive contents through the symlink to the attacker-chosen directory. The existing safeextract function validates tar member names (zip-slip defense) but does not validate the output directory itself — it cannot detect that self.datapath is a symlink. This is the defining distinction between the archiveextraction (zip-slip) and insecurefscreatetoctou families. Vulnerability Details Predictable output directory (line 535-546) Check-then-create (line 621-622) Extraction through symlink (line 633-644) safeextract calls os.path.abspath(directory) on self.datapath —…
Recommended action: Upgrade to 1.2.14 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
ChatterBot versions up to 1.2.10 are vulnerable to a denial-of-service condition caused by improper database session and connection pool management. Concurrent invocations of the getresponse() method can exhaust the underlying SQLAlchemy connection pool, resulting in persistent service unavailability and requiring a manual restart to recover. Details ChatterBot relies on SQLAlchemy for database access and uses a connection pool with default limits. The getresponse() method does not enforce concurrency limits, rate limiting, or explicit session lifecycle controls. When multiple threads concurrently invoke getresponse(), database connections are rapidly consumed and not released in a timely manner. This leads to exhaustion of the SQLAlchemy QueuePool, causing subsequent requests to block and eventually fail with a TimeoutError. This issue can be triggered without authentication in deployments where ChatterBot is exposed as a chatbot service, making it exploitable by remote…
Recommended action: Upgrade to 1.2.11 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.