Skip to content
This repository was archived by the owner on Jun 16, 2026. It is now read-only.

πŸ›‘οΈ Sentinel: [CRITICAL] Fix ACE vulnerability in _safe_eval_type string evaluation#395

Open
bashandbone wants to merge 1 commit into
mainfrom
sentinel/fix-ace-in-eval-type-5687974914215770184
Open

πŸ›‘οΈ Sentinel: [CRITICAL] Fix ACE vulnerability in _safe_eval_type string evaluation#395
bashandbone wants to merge 1 commit into
mainfrom
sentinel/fix-ace-in-eval-type-5687974914215770184

Conversation

@bashandbone

@bashandbone bashandbone commented Jun 14, 2026

Copy link
Copy Markdown
Contributor

🚨 Severity: CRITICAL
πŸ’‘ Vulnerability: The AST validation logic in _safe_eval_type (src/codeweaver/core/di/container.py) permitted generic ast.Call nodes. Since the subsequent evaluation used eval() with the module's global namespace, this allowed for Arbitrary Code Execution (ACE) if an attacker could inject an arbitrary function call into a string-based type annotation.
🎯 Impact: An attacker who controls configuration or input that is parsed as a string-based type annotation could execute arbitrary shell commands or malicious Python code within the application context, completely compromising the host system.
πŸ”§ Fix: Modified the TypeValidator to explicitly intercept and strictly whitelist ast.Call nodes to only allow safe metadata-constructing functions like Depends, depends, Field, Parameter, Tag, and PrivateAttr. Added # noqa: C901 to suppress McCabe complexity warnings from the added branches.
βœ… Verification: Verified by running unit tests (pytest tests/unit/core/di/) and ensuring that eval() on type strings correctly raises a TypeError when malicious functions are attempted while continuing to allow required dependency injection metadata calls.


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

Summary by Sourcery

Tighten validation of string-based type annotations to prevent arbitrary code execution during safe type evaluation.

Bug Fixes:

  • Reject unsafe function calls in _safe_eval_type by whitelisting allowed ast.Call targets when evaluating type strings.

Documentation:

  • Extend Sentinel security log with details of the new restriction on ast.Call nodes during type string evaluation.

…ng evaluation

Co-authored-by: bashandbone <89049923+bashandbone@users.noreply.github.com>
@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

sourcery-ai Bot commented Jun 14, 2026

Copy link
Copy Markdown
Contributor
Reviewer's guide (collapsed on small PRs)

Reviewer's Guide

Tightens the AST-based validation in _safe_eval_type to only allow a small, explicit set of safe function calls in type-string evaluation, and documents the security incident and mitigation in the Sentinel security log.

Sequence diagram for updated _safe_eval_type AST call validation

sequenceDiagram
    participant Caller
    participant Container
    participant TypeValidator
    participant eval

    Caller->>Container: _safe_eval_type(type_str, globalns)
    Container->>TypeValidator: visit(parsed_ast)
    TypeValidator->>TypeValidator: generic_visit(node)
    alt node is ast.Call
        TypeValidator->>TypeValidator: [extract func_name]
        alt func_name in allowed_calls
            TypeValidator-->>Container: validation_ok
            Container->>eval: eval(type_str, globalns)
            eval-->>Container: evaluated_type
            Container-->>Caller: evaluated_type
        else func_name not in allowed_calls
            TypeValidator-->>Container: raise TypeError
            Container-->>Caller: TypeError
        end
    else node is not ast.Call
        TypeValidator-->>Container: validation_ok
        Container->>eval: eval(type_str, globalns)
        eval-->>Container: evaluated_type
        Container-->>Caller: evaluated_type
    end
Loading

File-Level Changes

Change Details Files
Harden AST validation in _safe_eval_type to prevent arbitrary code execution from string-based type annotations.
  • Mark _safe_eval_type with # noqa: C901 to suppress McCabe complexity warnings due to expanded validation logic.
  • Extend TypeValidator.generic_visit to detect ast.Call nodes within parsed type strings.
  • Extract the called function name from ast.Call nodes, supporting both ast.Name and ast.Attribute forms.
  • Enforce a strict whitelist of allowed call targets (Depends, depends, Field, PrivateAttr, Tag, Parameter) and raise TypeError for any other calls, blocking unsafe evaluation paths.
src/codeweaver/core/di/container.py
Record the ACE vulnerability and mitigation details in the Sentinel security history documentation.
  • Add a dated Sentinel entry describing the vulnerability arising from unrestricted ast.Call handling in _safe_eval_type.
  • Document the security learning around eval with module globals and the need to constrain ast.Call nodes.
  • Document the prevention strategy based on whitelisting safe metadata functions for type resolution.
.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.

@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.

@sourcery-ai sourcery-ai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Hey - I've left some high level feedback:

  • Consider extracting the TypeValidator call-handling logic (and possibly the whole validator) into a dedicated helper/class or module-level function instead of suppressing C901, which will keep _safe_eval_type simpler and easier to maintain as additional cases are added.
  • The allowed_calls set is recreated on every ast.Call visit; moving this to a module- or class-level constant (e.g. ALLOWED_TYPE_CALLS) would avoid repeated allocations and also centralize the whitelist for easier future updates.
Prompt for AI Agents
Please address the comments from this code review:

## Overall Comments
- Consider extracting the `TypeValidator` call-handling logic (and possibly the whole validator) into a dedicated helper/class or module-level function instead of suppressing C901, which will keep `_safe_eval_type` simpler and easier to maintain as additional cases are added.
- The `allowed_calls` set is recreated on every `ast.Call` visit; moving this to a module- or class-level constant (e.g. `ALLOWED_TYPE_CALLS`) would avoid repeated allocations and also centralize the whitelist for easier future updates.

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant