demo: smoke-test PR for MAS-Ops review pipeline #2

cursor · 2026-05-30T22:28:09Z

Mutable default argument creates persistent shared cache

Medium Severity

Using a mutable default argument (cache={}) means the dictionary is shared across all calls to get_user for the lifetime of the process. The cache can never be invalidated, so stale data will be returned indefinitely after the first lookup for a given user_id. This is a well-known Python gotcha that leads to surprising behavior.

^{Reviewed by Cursor Bugbot for commit f0bfbf3. Configure here.}

kilo-code-bot · 2026-05-30T22:29:57Z

WARNING: Mutable default argument cache={} - shared between function calls. Use None as default and create a new dict inside the function.

cubic-dev-ai · 2026-05-30T22:31:19Z

P1: cache={} creates shared state across calls; use None and initialize inside the function to avoid cross-request/stale cache behavior.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At backend/app/_masops_smoke.py, line 4: <comment>`cache={}` creates shared state across calls; use `None` and initialize inside the function to avoid cross-request/stale cache behavior.</comment> <file context> @@ -0,0 +1,19 @@ +import sqlite3 + + +def get_user(db_path, user_id, cache={}): + if user_id in cache: + return cache[user_id] </file context>

cubic-dev-ai · 2026-05-30T22:31:19Z

P1: The cache is keyed solely by user_id, but the function accepts different db_path values. If the same user_id is looked up against a second database, the cached result from the first database is returned without querying the new one. Include db_path in the cache key.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At backend/app/_masops_smoke.py, line 5: <comment>The cache is keyed solely by `user_id`, but the function accepts different `db_path` values. If the same `user_id` is looked up against a second database, the cached result from the first database is returned without querying the new one. Include `db_path` in the cache key.</comment> <file context> @@ -0,0 +1,19 @@ + + +def get_user(db_path, user_id, cache={}): + if user_id in cache: + return cache[user_id] + conn = sqlite3.connect(db_path) </file context>

chatgpt-codex-connector · 2026-05-30T22:27:54Z

Include the database path in the cache key

When this helper is called for more than one SQLite database in the same process, the shared default cache is keyed only by user_id, so looking up the same ID in a second db_path returns rows from the first database without opening the second one. Scope the cache per database or include db_path in the key to avoid cross-database stale results.

Useful? React with 👍 / 👎.

cubic-dev-ai · 2026-05-30T22:31:20Z

P1: The sqlite3 connection is never closed. Every non-cached call to get_user leaks a connection, eventually exhausting file descriptors or database locks. Use a context manager (with sqlite3.connect(db_path) as conn:) or explicitly call conn.close() after use.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At backend/app/_masops_smoke.py, line 7: <comment>The `sqlite3` connection is never closed. Every non-cached call to `get_user` leaks a connection, eventually exhausting file descriptors or database locks. Use a context manager (`with sqlite3.connect(db_path) as conn:`) or explicitly call `conn.close()` after use.</comment> <file context> @@ -0,0 +1,19 @@ +def get_user(db_path, user_id, cache={}): + if user_id in cache: + return cache[user_id] + conn = sqlite3.connect(db_path) + cur = conn.cursor() + cur.execute("SELECT * FROM users WHERE id = '%s'" % user_id) </file context>

chatgpt-codex-connector · 2026-05-30T22:27:54Z

Parameterize the user lookup query

If user_id can come from a request or other untrusted input, interpolating it directly into the SQL lets values like ' OR '1'='1 alter the predicate and return unintended user rows. Use a parameterized SQLite query instead of string formatting so the ID is treated as data.

Useful? React with 👍 / 👎.

cursor · 2026-05-30T22:28:09Z

SQL injection via string interpolation in query

High Severity

user_id is directly interpolated into the SQL query string using % formatting, creating a classic SQL injection vulnerability. A malicious user_id value like ' OR '1'='1 would bypass filtering and leak all rows. The sqlite3 module supports parameterized queries (? placeholders) which would prevent this.

^{Reviewed by Cursor Bugbot for commit f0bfbf3. Configure here.}

kilo-code-bot · 2026-05-30T22:29:57Z

CRITICAL: SQL injection vulnerability - using string formatting in SQL query. Use parameterized queries: cur.execute("SELECT * FROM users WHERE id = ?", (user_id,))

cubic-dev-ai · 2026-05-30T22:31:19Z

P0: This query is vulnerable to SQL injection because it interpolates user_id directly into SQL.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At backend/app/_masops_smoke.py, line 9: <comment>This query is vulnerable to SQL injection because it interpolates `user_id` directly into SQL.</comment> <file context> @@ -0,0 +1,19 @@ + return cache[user_id] + conn = sqlite3.connect(db_path) + cur = conn.cursor() + cur.execute("SELECT * FROM users WHERE id = '%s'" % user_id) + rows = cur.fetchall() + cache[user_id] = rows </file context>

Suggested change

cur.execute("SELECT * FROM users WHERE id = '%s'" % user_id)

cur.execute("SELECT * FROM users WHERE id = ?", (user_id,))

cursor · 2026-05-30T22:28:09Z

Database connection is never closed, causing resource leak

Medium Severity

The sqlite3 connection opened via sqlite3.connect(db_path) is never closed — there's no conn.close() call and no with context manager. Every non-cached call to get_user leaks a connection, which can exhaust file descriptors or database locks over time.

^{Reviewed by Cursor Bugbot for commit f0bfbf3. Configure here.}

kilo-code-bot · 2026-05-30T22:29:57Z

WARNING: Mutable default argument items=[] - shared between function calls. Use None as default and create a new list inside the function.

kilo-code-bot · 2026-05-30T22:29:57Z

WARNING: Bare except: catches all exceptions including SystemExit and KeyboardInterrupt. Catch specific exceptions like IndexError instead.

cubic-dev-ai · 2026-05-30T22:31:20Z

P2: Bare except: catches all BaseException subclasses including KeyboardInterrupt and SystemExit, making the process unresponsive to interrupt/shutdown signals. Narrow this to except (IndexError, TypeError): or at minimum except Exception:.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At backend/app/_masops_smoke.py, line 18: <comment>Bare `except:` catches all `BaseException` subclasses including `KeyboardInterrupt` and `SystemExit`, making the process unresponsive to interrupt/shutdown signals. Narrow this to `except (IndexError, TypeError):` or at minimum `except Exception:`.</comment> <file context> @@ -0,0 +1,19 @@ +def first_or_none(items=[]): + try: + return items[0] + except: + pass </file context>

cursor · 2026-05-30T22:28:10Z

Bare except silently swallows critical system exceptions

Low Severity

The bare except: in first_or_none catches all exceptions deriving from BaseException, including KeyboardInterrupt, SystemExit, and GeneratorExit. This silently suppresses signals that are meant to terminate the process, making the program unresponsive to interrupt signals or graceful shutdown requests when this code path is active. Only IndexError (and perhaps TypeError) is expected here.

^{Reviewed by Cursor Bugbot for commit f0bfbf3. Configure here.}

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

demo: smoke-test PR for MAS-Ops review pipeline #2

Diff view

Diff view

There are no files selected for viewing

cursor Bot May 30, 2026

Uh oh!

kilo-code-bot Bot May 30, 2026

Uh oh!

cubic-dev-ai Bot May 30, 2026

Uh oh!

cubic-dev-ai Bot May 30, 2026

Uh oh!

chatgpt-codex-connector Bot May 30, 2026

Uh oh!

cubic-dev-ai Bot May 30, 2026

Uh oh!

chatgpt-codex-connector Bot May 30, 2026

Uh oh!

cursor Bot May 30, 2026

Uh oh!

kilo-code-bot Bot May 30, 2026

Uh oh!

cubic-dev-ai Bot May 30, 2026

Uh oh!

cursor Bot May 30, 2026

Uh oh!

kilo-code-bot Bot May 30, 2026

Uh oh!

kilo-code-bot Bot May 30, 2026

Uh oh!

cubic-dev-ai Bot May 30, 2026

Uh oh!

cursor Bot May 30, 2026

Uh oh!

demo: smoke-test PR for MAS-Ops review pipeline #2

demo: smoke-test PR for MAS-Ops review pipeline #2

Uh oh!

Uh oh!

Diff view

Diff view

There are no files selected for viewing

cursor Bot May 30, 2026

Choose a reason for hiding this comment

Mutable default argument creates persistent shared cache

Uh oh!

kilo-code-bot Bot May 30, 2026

Choose a reason for hiding this comment

Uh oh!

cubic-dev-ai Bot May 30, 2026

Choose a reason for hiding this comment

Uh oh!

cubic-dev-ai Bot May 30, 2026

Choose a reason for hiding this comment

Uh oh!

chatgpt-codex-connector Bot May 30, 2026

Choose a reason for hiding this comment

Uh oh!

cubic-dev-ai Bot May 30, 2026

Choose a reason for hiding this comment

Uh oh!

chatgpt-codex-connector Bot May 30, 2026

Choose a reason for hiding this comment

Uh oh!

cursor Bot May 30, 2026

Choose a reason for hiding this comment

SQL injection via string interpolation in query

Uh oh!

kilo-code-bot Bot May 30, 2026

Choose a reason for hiding this comment

Uh oh!

cubic-dev-ai Bot May 30, 2026

Choose a reason for hiding this comment

Uh oh!

cursor Bot May 30, 2026

Choose a reason for hiding this comment

Database connection is never closed, causing resource leak

Uh oh!

kilo-code-bot Bot May 30, 2026

Choose a reason for hiding this comment

Uh oh!

kilo-code-bot Bot May 30, 2026

Choose a reason for hiding this comment

Uh oh!

cubic-dev-ai Bot May 30, 2026

Choose a reason for hiding this comment

Uh oh!

cursor Bot May 30, 2026

Choose a reason for hiding this comment

Bare except silently swallows critical system exceptions

Uh oh!