Skip to content

fix: Control default deny list via an env var#5862

Merged
christopherholland-workday merged 2 commits intomainfrom
deny-list-fix
Mar 2, 2026
Merged

fix: Control default deny list via an env var#5862
christopherholland-workday merged 2 commits intomainfrom
deny-list-fix

Conversation

@christopherholland-workday
Copy link
Copy Markdown
Contributor

In a previous fix we hardcoded a default deny list of endpoints that should not be accessible: #5708

This is a little too restricting for users hosting Flowise themselves. This PR controls the default deny list via a new environment variable, which defaults to true and must explicitly be set to false to allow calls to local endpoints.

Testing

  1. Recreated the issue locally (access denied):
Screenshot 2026-02-27 at 12 00 14 PM
  1. Restarted flowise with the changes and HTTP_SECURITY_CHECK=false (access granted, ignore that the call fail, it still hit the endpoint which is what we are fixing):
Screenshot 2026-02-27 at 11 58 20 AM
  1. Tested with HTTP_SECURITY_CHECK=true and the env var missing and access was denied

@gemini-code-assist
Copy link
Copy Markdown
Contributor

Summary of Changes

Hello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request enhances the network security configuration by making the default HTTP deny list optional. Previously hardcoded, this list can now be disabled via an environment variable, addressing a limitation for self-hosted Flowise instances that require local network access. This change improves deployment flexibility while maintaining a secure-by-default posture.

Highlights

  • Configurable Default Deny List: Introduced a new environment variable, HTTP_SECURITY_CHECK, to control whether the default HTTP deny list (localhost, private IPs, cloud metadata endpoints) is applied. This provides greater flexibility for self-hosted instances.
  • Default Security Posture: The HTTP_SECURITY_CHECK variable defaults to true, maintaining the secure default behavior. Users must explicitly set it to false to disable the default deny list and allow calls to local endpoints.
  • Custom Deny List Enforcement: Regardless of the HTTP_SECURITY_CHECK setting, any custom entries defined in HTTP_DENY_LIST will still be enforced, allowing users to add their own specific restrictions.
Changelog
  • docker/.env.example
    • Added HTTP_SECURITY_CHECK environment variable with detailed comments explaining its purpose and usage.
  • docker/docker-compose-queue-prebuilt.yml
    • Included HTTP_SECURITY_CHECK in the environment variables passed to the flowise and worker services.
  • docker/docker-compose.yml
    • Included HTTP_SECURITY_CHECK in the environment variables passed to the flowise service.
  • docker/worker/.env.example
    • Added HTTP_SECURITY_CHECK environment variable with detailed comments explaining its purpose and usage.
  • docker/worker/docker-compose.yml
    • Included HTTP_SECURITY_CHECK in the environment variables passed to the worker service.
  • packages/components/src/httpSecurity.ts
    • Modified the getHttpDenyList function to conditionally include the DEFAULT_DENY_LIST based on the HTTP_SECURITY_CHECK environment variable.
  • packages/server/.env.example
    • Added HTTP_SECURITY_CHECK environment variable with detailed comments explaining its purpose and usage.
  • packages/server/src/commands/base.ts
    • Added HTTP_SECURITY_CHECK as a configurable flag for base commands.
Activity
  • The author recreated the issue locally where access was denied due to the hardcoded deny list.
  • The author restarted Flowise with HTTP_SECURITY_CHECK=false and confirmed access was granted to the local endpoint.
  • The author tested with HTTP_SECURITY_CHECK=true (and the env var missing) and confirmed access was denied, validating the default secure behavior.
Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

Copy link
Copy Markdown
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

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

Code Review

This pull request introduces the HTTP_SECURITY_CHECK environment variable to control the default HTTP deny list, offering flexibility for self-hosted instances requiring local network access while maintaining a secure default. However, the current deny list implementation has security weaknesses. Hostnames in HTTP_DENY_LIST are not effectively blocked as the check only compares resolved IP addresses. Furthermore, the system is vulnerable to SSRF bypasses using IPv4-mapped IPv6 addresses, which are not covered by the deny list or its matching logic.

return [...new Set([...DEFAULT_DENY_LIST, ...customList])]
}
return DEFAULT_DENY_LIST
return customList
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.

security-medium medium

The getHttpDenyList function returns a list that can contain hostnames, as documented in the updated JSDoc (line 33). However, the isDeniedIP function only compares the target IP address against the entries in the list. It does not check the target hostname against the entries, nor does it resolve the entries in the list to IP addresses. This means that any hostname added to HTTP_DENY_LIST will not be effectively blocked unless it is also an IP address or CIDR range. This is particularly dangerous when HTTP_SECURITY_CHECK is set to false, as the default IP-based protections are removed and the user may rely on the custom deny list for security.

Remediation: Update the security check logic to either resolve hostnames in the deny list to IP addresses or check the target hostname against the deny list before resolution.

@christopherholland-workday christopherholland-workday merged commit 219b040 into main Mar 2, 2026
7 checks passed
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.

Error: Access to this host is denied by policy.

3 participants