7.5

CVSS Score

3.1

-

CVSS Score

Basic Information

Concerned about an active attack path?

Talk to our security experts and see Miggo in action.

Miggo Vulnerability Database

→

CVE-2026-23842

CVE-2026-23842: ChatterBot has Denial of Service via Database Connection Pool Exhaustion

ChatterBot is a machine learning, conversational dialog engine for creating chat bots. 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 get_response() method can exhaust the underlying SQLAlchemy connection pool, resulting in persistent service unavailability and requiring a manual restart to recover. Version 1.2.11 fixes the issue.

(GitHub Advisory)

Miggo Vulnerability Database

→

CVE-2026-23842

CVE-2026-23842:

7.5

CVSS Score

3.1

-

CVSS Score

Basic Information

Is this CVE running in your environment?

Easily map the attack path and prioritize which CVEs are a threat to your organization

Validate Exposure

Technical Details

Package Name	Ecosystem	Vulnerable Versions	First Patched Version
chatterbot	pip	<= 1.2.10	1.2.11

Technical Details

Vulnerability Intelligence
Miggo AI

Root Cause Analysis

The vulnerability is a denial-of-service (DoS) in ChatterBot caused by the exhaustion of the database connection pool. The root cause lies in the chatterbot.storage.sql_storage.SQLStorageAdapter class, which is responsible for all database interactions.

The SQLStorageAdapter.__init__ method improperly configured the SQLAlchemy session maker. It used sessionmaker directly, which is not thread-safe for managing sessions across concurrent requests. This meant that when multiple threads (e.g., from a web server) called the get_response method on the chatbot, they would receive sessions that were not isolated, leading to race conditions and improper session lifecycle management.

Furthermore, several methods within SQLStorageAdapter that perform database operations (such as filter, update, count, etc.) did not have robust error handling to ensure that database sessions were always closed and their connections returned to the pool. For example, if an exception occurred during a database query, the session.close() call would be skipped, causing a connection to leak.

Under concurrent load, as described in the proof-of-concept, these connection leaks accumulate rapidly, exhausting the SQLAlchemy connection pool. Once the pool is exhausted, all subsequent requests to the chatbot that require a database connection will hang and eventually time out, rendering the application unresponsive and effectively causing a denial of service.

The patch addresses these issues by:

Introducing scoped_session in the __init__ method to create a thread-local session registry. This ensures that each thread gets its own isolated database session.
Wrapping database operations within try...finally blocks in all methods that interact with the database. This guarantees that session.close() is called even if an exception occurs, preventing connection leaks.
Adding connection pool configuration parameters to create_engine to control the pool size and behavior, providing another layer of defense against exhaustion.

Vulnerable functions

SQLStorageAdapter.__init__

chatterbot/storage/sql_storage.py

The constructor for the `SQLStorageAdapter` is the primary source of the vulnerability. It initializes the SQLAlchemy session using `sessionmaker` without `scoped_session`, which makes the session management not thread-safe. This improper configuration is the root cause of the database connection pool exhaustion when the chatbot handles concurrent requests, as each thread of execution does not have its own isolated session.

SQLStorageAdapter.count

chatterbot/storage/sql_storage.py

This function was vulnerable because it did not ensure the database session was closed if an exception occurred. It acquires a session from the non-thread-safe session pool, and in a concurrent environment, an unhandled exception could lead to a connection leak, contributing to the exhaustion of the connection pool.

SQLStorageAdapter.remove

chatterbot/storage/sql_storage.py

Similar to other methods in this class, `remove` was vulnerable due to the lack of guaranteed session closure. It used a session from the improperly configured session factory, and any exception could prevent the session from being closed, thus leaking a database connection and contributing to the denial-of-service vulnerability.

SQLStorageAdapter.filter

chatterbot/storage/sql_storage.py

The `filter` function, being a generator, was particularly susceptible to leaking connections. If the consumer of the generator did not iterate through all results or an exception occurred, the `session.close()` call at the end of the function would not be reached. This, combined with the non-thread-safe session, would cause connection leaks under concurrent access.

SQLStorageAdapter.create_many

chatterbot/storage/sql_storage.py

This function was vulnerable because it did not wrap its database operations in a `try...finally` block. An exception during the `session.add_all()` or `session.commit()` calls would prevent `session.close()` from being executed, leading to a connection leak from the pool.

SQLStorageAdapter.update

chatterbot/storage/sql_storage.py

The `update` function was vulnerable to connection leaks. It acquired a session from the non-thread-safe pool and did not have error handling to ensure the session was closed if an exception occurred during the update process. This flaw would contribute to connection pool exhaustion when multiple threads are updating statements concurrently.

SQLStorageAdapter.get_random

chatterbot/storage/sql_storage.py

This function was vulnerable as it did not guarantee the closure of the database session in case of an error. For instance, if the database was empty and `self.count()` returned 0, an exception would be raised before the session was closed, leading to a connection leak.

Vulnerability Intelligence
Miggo AI

Unlock WAF rules for this CVE

Generate vendor-ready rules for the observed attack patterns, plus reasoning and safe deployment guidance

Get WAF rules

WAF Protection Rules

WAF Rule

W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.

Reasoning

*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.