Skip to content

🛡️ Sentinel: [CRITICAL] Fix arbitrary code execution in dependency container#359

Open
bashandbone wants to merge 1 commit into
mainfrom
sentinel/fix-ace-in-di-container-3732493649190943774
Open

🛡️ Sentinel: [CRITICAL] Fix arbitrary code execution in dependency container#359
bashandbone wants to merge 1 commit into
mainfrom
sentinel/fix-ace-in-di-container-3732493649190943774

Conversation

@bashandbone
Copy link
Copy Markdown
Contributor

@bashandbone bashandbone commented May 23, 2026

🚨 Severity: CRITICAL
💡 Vulnerability: The _safe_eval_type function allowed arbitrary ast.Call execution during Pydantic/dependency string type resolution (Arbitrary Code Execution via eval()).
🎯 Impact: Attackers who could control a configuration that maps to a type string or those manipulating dependency annotations could execute arbitrary callables directly from the OS, bypassing access controls.
🔧 Fix: Removed ast.Call from the global unconditionally allowed list in TypeValidator.generic_visit. Implemented a targeted allowlist allowing only explicitly required dependency wrappers (Depends, depends, Field, PrivateAttr, Tag).
✅ Verification: Ran mise //:test on the tests/unit/core/ and the system passed successfully without regressions. Tested the local exploit bypassing the ast logic and it threw a forbidden exception safely.


PR created automatically by Jules for task 3732493649190943774 started by @bashandbone

Summary by Sourcery

Harden AST-based type string evaluation in the dependency injection container to prevent arbitrary function execution and document the security fix in Sentinel notes.

Bug Fixes:

  • Block arbitrary ast.Call execution in _safe_eval_type by only allowing specific, trusted dependency wrappers in type annotations.

Documentation:

  • Add Sentinel security incident entry describing the unsafe AST evaluation vulnerability, its impact, and prevention guidance.

…Call resolution to a strict whitelist.

Co-authored-by: bashandbone <89049923+bashandbone@users.noreply.github.com>
Copilot AI review requested due to automatic review settings May 23, 2026 19:41
@google-labs-jules
Copy link
Copy Markdown
Contributor

👋 Jules, reporting for duty! I'm here to lend a hand with this pull request.

When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down.

I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job!

For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with @jules. You can find this option in the Pull Request section of your global Jules UI settings. You can always switch back!

New to Jules? Learn more at jules.google/docs.


For security, I will only act on instructions from the user who triggered this task.

@sourcery-ai
Copy link
Copy Markdown
Contributor

sourcery-ai Bot commented May 23, 2026

Reviewer's guide (collapsed on small PRs)

Reviewer's Guide

Tightens AST-based type string evaluation in the DI container to prevent arbitrary code execution by restricting allowed function calls and documenting the security fix in the Sentinel log.

Sequence diagram for secured AST type evaluation in DI container

sequenceDiagram
    actor Configurator
    participant Container as DIContainer
    participant TypeValidator
    participant ast

    Configurator->>DIContainer: _safe_eval_type(type_string)
    DIContainer->>ast: parse(type_string, mode="eval")
    ast-->>DIContainer: ast.Expression
    DIContainer->>TypeValidator: visit(ast.Expression)

    loop walk_nodes
        TypeValidator->>TypeValidator: generic_visit(node)
        alt node is ast.Call
            TypeValidator->>TypeValidator: check node.func.id in {Depends, depends, Field, PrivateAttr, Tag}
            alt allowed wrapper
                TypeValidator-->>TypeValidator: continue traversal
            else forbidden call
                TypeValidator-->>DIContainer: raise TypeError("Forbidden function call in type string")
                DIContainer-->>Configurator: reject type string
            end
        else other allowed node types
            TypeValidator-->>TypeValidator: continue traversal
        else forbidden node type
            TypeValidator-->>DIContainer: raise TypeError("Forbidden AST node in type string")
            DIContainer-->>Configurator: reject type string
        end
    end
Loading

File-Level Changes

Change Details Files
Harden AST visitor used in type string evaluation to only permit a small allowlist of safe function calls and otherwise reject disallowed call/AST node patterns.
  • Introduce a dedicated check for ast.Call nodes that only permits calls where node.func is a simple ast.Name with an identifier in the explicit allowlist {"Depends", "depends", "Field", "PrivateAttr", "Tag"}.
  • Raise a TypeError with a descriptive message when encountering forbidden function calls during type evaluation.
  • Treat ast.keyword nodes as always allowed without relying on the generic isinstance allowlist path.
  • Remove ast.Call and ast.keyword from the general allowed-node tuple so that calls outside the allowlist and other forbidden nodes are rejected.
src/codeweaver/core/di/container.py
Document the newly discovered ACE vulnerability and mitigation in the Sentinel security log.
  • Add an entry describing the unsafe allowance of ast.Call in _safe_eval_type within the DI container and how it enabled arbitrary callable execution.
  • Record the security learning around AST evaluation and the requirement for a strict allowlist on function calls in type strings.
  • Document preventative guidance to avoid open-ended AST evaluation and enforce explicit node and callable allowlists.
.jules/sentinel.md

Tips and commands

Interacting with Sourcery

  • Trigger a new review: Comment @sourcery-ai review on the pull request.
  • Continue discussions: Reply directly to Sourcery's review comments.
  • Generate a GitHub issue from a review comment: Ask Sourcery to create an
    issue from a review comment by replying to it. You can also reply to a
    review comment with @sourcery-ai issue to create an issue from it.
  • Generate a pull request title: Write @sourcery-ai anywhere in the pull
    request title to generate a title at any time. You can also comment
    @sourcery-ai title on the pull request to (re-)generate the title at any time.
  • Generate a pull request summary: Write @sourcery-ai summary anywhere in
    the pull request body to generate a PR summary at any time exactly where you
    want it. You can also comment @sourcery-ai summary on the pull request to
    (re-)generate the summary at any time.
  • Generate reviewer's guide: Comment @sourcery-ai guide on the pull
    request to (re-)generate the reviewer's guide at any time.
  • Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
    pull request to resolve all Sourcery comments. Useful if you've already
    addressed all the comments and don't want to see them anymore.
  • Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
    request to dismiss all existing Sourcery reviews. Especially useful if you
    want to start fresh with a new review - don't forget to comment
    @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

  • Enable or disable review features such as the Sourcery-generated pull request
    summary, the reviewer's guide, and others.
  • Change the review language.
  • Add, remove or edit custom review instructions.
  • Adjust other review settings.

Getting Help

@github-actions
Copy link
Copy Markdown
Contributor

🤖 Hi @bashandbone, I've received your request, and I'm working on it now! You can track my progress in the logs for more details.

Copy link
Copy Markdown
Contributor

@sourcery-ai sourcery-ai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey - I've reviewed your changes and they look great!


Sourcery is free for open source - if you like our reviews please consider sharing them ✨
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.

@github-actions
Copy link
Copy Markdown
Contributor

🤖 I'm sorry @bashandbone, but I was unable to process your request. Please see the logs for more details.

Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR hardens CodeWeaver’s DI container string-type evaluation (_safe_eval_type) to prevent arbitrary function execution when resolving annotations from strings, and records the incident in Sentinel notes.

Changes:

  • Restricts ast.Call during AST validation to an explicit allowlist of wrapper functions used in dependency/type metadata.
  • Removes unconditional allowance of ast.Call/ast.keyword from the generic allowed-node list and handles them explicitly.
  • Documents the vulnerability, learning, and prevention guidance in .jules/sentinel.md.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File Description
src/codeweaver/core/di/container.py Tightens AST validation for string annotation evaluation by allowlisting specific call wrappers.
.jules/sentinel.md Adds a Sentinel entry documenting the unsafe AST evaluation RCE/ACE issue and mitigation.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment on lines +114 to +117
if isinstance(node, ast.Call):
# Restricting arbitrary function calls during type evaluation prevents ACE vulnerabilities
if not isinstance(node.func, ast.Name) or node.func.id not in {"Depends", "depends", "Field", "PrivateAttr", "Tag"}:
raise TypeError(f"Forbidden function call in type string: {node.func.id if isinstance(node.func, ast.Name) else type(node.func).__name__}")
Comment on lines +114 to +117
if isinstance(node, ast.Call):
# Restricting arbitrary function calls during type evaluation prevents ACE vulnerabilities
if not isinstance(node.func, ast.Name) or node.func.id not in {"Depends", "depends", "Field", "PrivateAttr", "Tag"}:
raise TypeError(f"Forbidden function call in type string: {node.func.id if isinstance(node.func, ast.Name) else type(node.func).__name__}")
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants