wp-graphql/wp-graphql

Engine: GuardDog · Supply-chain attack heuristics
Counts towards: Malicious pattern
File: /websites/wpgraphql.com/.yarn/releases/yarn-1.22.19.cjs line 57
Likely real: Yes, 99% confidence

Detects suspicious autostart persistence mechanisms [threat-filesystem-autostart]

/******/ 			function getModuleExports() { return module; };
/******/ 		__webpack_require__.d(getter, 'a', getter);
/******/ 		return getter;
/******/ 	};

Engine: GuardDog · Supply-chain attack heuristics
Counts towards: Malicious pattern
File: /websites/wpgraphql.com/.yarn/releases/yarn-1.22.19.cjs line 128141
Likely real: Yes, 99% confidence

Detects suspicious autostart persistence mechanisms [threat-filesystem-autostart]

...le":true},"application/vnd.etsi.tsl.der":{"source":"iana"},"application/vnd.eudora.data":{"source":"iana"},"application/vnd.evolv.ecig.profile":{"source":"iana"},"application/vnd.evolv.ecig.settings":{"source":"iana"},"application/vnd.evolv.ecig.them...

Engine: GuardDog · Supply-chain attack heuristics
Counts towards: Malicious pattern
File: /websites/wpgraphql.com/.yarn/releases/yarn-1.22.19.cjs line 5523
Likely real: Yes, 99% confidence

Detects suspicious autostart persistence mechanisms [threat-filesystem-autostart]

'ed25519': {
		parts: ['A'],
		sizePart: 'A'
	}

Engine: GuardDog · Supply-chain attack heuristics
Counts towards: Malicious pattern
File: /websites/wpgraphql.com/.yarn/releases/yarn-1.22.19.cjs line 85060
Likely real: Yes, 98% confidence

Detects URLs to suspicious domains often used for exfiltration or C2 [threat-network-exfiltration]

...moattachments.org":true,"net.ru":true,"org.ru":true,"pp.ru":true,"bitballoon.com":true,"netlify.com":true,"4u.com":true,"ngrok.io":true,"nh-serv.co.uk":true,"nfshost.com":true,"nsupdate.info":true,"nerdpol.ovh":true,"blogsyte.com":true,"brasilia.me":...

Engine: GuardDog · Supply-chain attack heuristics
Counts towards: Malicious pattern
File: /websites/wpgraphql.com/.yarn/releases/yarn-1.22.19.cjs line 36414
Likely real: Yes, 96% confidence

Detects download-and-execute patterns: fetching a remote file then executing it [threat-process-download-exec]

try {
    return !!exec();
  } catch (e) {
    return true;

Engine: GuardDog · Supply-chain attack heuristics
Counts towards: Malicious pattern
File: /websites/wpgraphql.com/.yarn/releases/yarn-1.22.19.cjs line 39199
Likely real: Yes, 95% confidence

Detects download-and-execute patterns: fetching a remote file then executing it [threat-process-download-exec]

try {
    return { e: false, v: exec() };
  } catch (e) {
    return { e: true, v: e };

Engine: GuardDog · Supply-chain attack heuristics
Counts towards: Malicious pattern
File: /websites/wpgraphql.com/.yarn/releases/yarn-1.22.19.cjs line 52756
Likely real: Yes, 95% confidence

Detects download-and-execute patterns: fetching a remote file then executing it [threat-process-download-exec]

arr[ITERATOR] = function () { return iter; };
    exec(arr);
  } catch (e) { /* empty */ }
  return safe;

Engine: GuardDog · Supply-chain attack heuristics
Counts towards: Malicious pattern
File: /websites/wpgraphql.com/.yarn/releases/yarn-1.22.19.cjs line 36414
Likely real: Yes, 91% confidence

Detects steganography decode followed by code execution [threat-runtime-obfuscation-steganography]

try {
    return !!exec();
  } catch (e) {
    return true;

Engine: GuardDog · Supply-chain attack heuristics
Counts towards: Malicious pattern
File: /websites/wpgraphql.com/.yarn/releases/yarn-1.22.19.cjs line 36414
Likely real: Yes, 91% confidence

Detects base64 decoding followed by code execution [threat-runtime-obfuscation-base64exec]

try {
    return !!exec();
  } catch (e) {
    return true;

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/workflows/lint.yml line 217
Likely real: Yes, 87% confidence

This workflow uses `secrets: inherit` to pass all of the calling workflow's secrets to a reusable workflow. This violates the principle of least privilege because the called workflow receives access to every secret in the repository, not just the ones it needs. If the called workflow is compromised or sourced from a third party, an attacker gains access to all repository secrets. Instead, explicitly pass only the secrets that the called workflow requires using the `secrets:` map, e.g. `secrets: { MY_SECRET: ${{ secrets.MY_SECRET }} }`.

secrets: inherit

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/workflows/smoke-test.yml line 271
Likely real: Yes, 87% confidence

This workflow uses `secrets: inherit` to pass all of the calling workflow's secrets to a reusable workflow. This violates the principle of least privilege because the called workflow receives access to every secret in the repository, not just the ones it needs. If the called workflow is compromised or sourced from a third party, an attacker gains access to all repository secrets. Instead, explicitly pass only the secrets that the called workflow requires using the `secrets:` map, e.g. `secrets: { MY_SECRET: ${{ secrets.MY_SECRET }} }`.

secrets: inherit

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/workflows/lint.yml line 207
Likely real: Yes, 87% confidence

This workflow uses `secrets: inherit` to pass all of the calling workflow's secrets to a reusable workflow. This violates the principle of least privilege because the called workflow receives access to every secret in the repository, not just the ones it needs. If the called workflow is compromised or sourced from a third party, an attacker gains access to all repository secrets. Instead, explicitly pass only the secrets that the called workflow requires using the `secrets:` map, e.g. `secrets: { MY_SECRET: ${{ secrets.MY_SECRET }} }`.

secrets: inherit

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/workflows/lint.yml line 197
Likely real: Yes, 87% confidence

This workflow uses `secrets: inherit` to pass all of the calling workflow's secrets to a reusable workflow. This violates the principle of least privilege because the called workflow receives access to every secret in the repository, not just the ones it needs. If the called workflow is compromised or sourced from a third party, an attacker gains access to all repository secrets. Instead, explicitly pass only the secrets that the called workflow requires using the `secrets:` map, e.g. `secrets: { MY_SECRET: ${{ secrets.MY_SECRET }} }`.

secrets: inherit

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/workflows/lint.yml line 150
Likely real: Yes, 87% confidence

This workflow uses `secrets: inherit` to pass all of the calling workflow's secrets to a reusable workflow. This violates the principle of least privilege because the called workflow receives access to every secret in the repository, not just the ones it needs. If the called workflow is compromised or sourced from a third party, an attacker gains access to all repository secrets. Instead, explicitly pass only the secrets that the called workflow requires using the `secrets:` map, e.g. `secrets: { MY_SECRET: ${{ secrets.MY_SECRET }} }`.

secrets: inherit

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/workflows/js-e2e-tests.yml line 216
Likely real: Yes, 87% confidence

This workflow uses `secrets: inherit` to pass all of the calling workflow's secrets to a reusable workflow. This violates the principle of least privilege because the called workflow receives access to every secret in the repository, not just the ones it needs. If the called workflow is compromised or sourced from a third party, an attacker gains access to all repository secrets. Instead, explicitly pass only the secrets that the called workflow requires using the `secrets:` map, e.g. `secrets: { MY_SECRET: ${{ secrets.MY_SECRET }} }`.

secrets: inherit

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/workflows/js-e2e-tests.yml line 185
Likely real: Yes, 87% confidence

This workflow uses `secrets: inherit` to pass all of the calling workflow's secrets to a reusable workflow. This violates the principle of least privilege because the called workflow receives access to every secret in the repository, not just the ones it needs. If the called workflow is compromised or sourced from a third party, an attacker gains access to all repository secrets. Instead, explicitly pass only the secrets that the called workflow requires using the `secrets:` map, e.g. `secrets: { MY_SECRET: ${{ secrets.MY_SECRET }} }`.

secrets: inherit

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/workflows/js-e2e-tests.yml line 158
Likely real: Yes, 87% confidence

This workflow uses `secrets: inherit` to pass all of the calling workflow's secrets to a reusable workflow. This violates the principle of least privilege because the called workflow receives access to every secret in the repository, not just the ones it needs. If the called workflow is compromised or sourced from a third party, an attacker gains access to all repository secrets. Instead, explicitly pass only the secrets that the called workflow requires using the `secrets:` map, e.g. `secrets: { MY_SECRET: ${{ secrets.MY_SECRET }} }`.

secrets: inherit

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/workflows/integration-tests.yml line 457
Likely real: Yes, 87% confidence

This workflow uses `secrets: inherit` to pass all of the calling workflow's secrets to a reusable workflow. This violates the principle of least privilege because the called workflow receives access to every secret in the repository, not just the ones it needs. If the called workflow is compromised or sourced from a third party, an attacker gains access to all repository secrets. Instead, explicitly pass only the secrets that the called workflow requires using the `secrets:` map, e.g. `secrets: { MY_SECRET: ${{ secrets.MY_SECRET }} }`.

secrets: inherit

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/workflows/integration-tests.yml line 374
Likely real: Yes, 87% confidence

This workflow uses `secrets: inherit` to pass all of the calling workflow's secrets to a reusable workflow. This violates the principle of least privilege because the called workflow receives access to every secret in the repository, not just the ones it needs. If the called workflow is compromised or sourced from a third party, an attacker gains access to all repository secrets. Instead, explicitly pass only the secrets that the called workflow requires using the `secrets:` map, e.g. `secrets: { MY_SECRET: ${{ secrets.MY_SECRET }} }`.

secrets: inherit

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/workflows/integration-tests.yml line 253
Likely real: Yes, 87% confidence

This workflow uses `secrets: inherit` to pass all of the calling workflow's secrets to a reusable workflow. This violates the principle of least privilege because the called workflow receives access to every secret in the repository, not just the ones it needs. If the called workflow is compromised or sourced from a third party, an attacker gains access to all repository secrets. Instead, explicitly pass only the secrets that the called workflow requires using the `secrets:` map, e.g. `secrets: { MY_SECRET: ${{ secrets.MY_SECRET }} }`.

secrets: inherit

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/workflows/integration-tests.yml line 315
Likely real: Yes, 87% confidence

This workflow uses `secrets: inherit` to pass all of the calling workflow's secrets to a reusable workflow. This violates the principle of least privilege because the called workflow receives access to every secret in the repository, not just the ones it needs. If the called workflow is compromised or sourced from a third party, an attacker gains access to all repository secrets. Instead, explicitly pass only the secrets that the called workflow requires using the `secrets:` map, e.g. `secrets: { MY_SECRET: ${{ secrets.MY_SECRET }} }`.

secrets: inherit

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/workflows/schema-linter.yml line 133
Likely real: Yes, 87% confidence

This workflow uses `secrets: inherit` to pass all of the calling workflow's secrets to a reusable workflow. This violates the principle of least privilege because the called workflow receives access to every secret in the repository, not just the ones it needs. If the called workflow is compromised or sourced from a third party, an attacker gains access to all repository secrets. Instead, explicitly pass only the secrets that the called workflow requires using the `secrets:` map, e.g. `secrets: { MY_SECRET: ${{ secrets.MY_SECRET }} }`.

secrets: inherit

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/workflows/schema-linter.yml line 147
Likely real: Yes, 87% confidence

This workflow uses `secrets: inherit` to pass all of the calling workflow's secrets to a reusable workflow. This violates the principle of least privilege because the called workflow receives access to every secret in the repository, not just the ones it needs. If the called workflow is compromised or sourced from a third party, an attacker gains access to all repository secrets. Instead, explicitly pass only the secrets that the called workflow requires using the `secrets:` map, e.g. `secrets: { MY_SECRET: ${{ secrets.MY_SECRET }} }`.

secrets: inherit

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/workflows/smoke-test.yml line 175
Likely real: Yes, 87% confidence

This workflow uses `secrets: inherit` to pass all of the calling workflow's secrets to a reusable workflow. This violates the principle of least privilege because the called workflow receives access to every secret in the repository, not just the ones it needs. If the called workflow is compromised or sourced from a third party, an attacker gains access to all repository secrets. Instead, explicitly pass only the secrets that the called workflow requires using the `secrets:` map, e.g. `secrets: { MY_SECRET: ${{ secrets.MY_SECRET }} }`.

secrets: inherit

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/workflows/smoke-test.yml line 204
Likely real: Yes, 87% confidence

This workflow uses `secrets: inherit` to pass all of the calling workflow's secrets to a reusable workflow. This violates the principle of least privilege because the called workflow receives access to every secret in the repository, not just the ones it needs. If the called workflow is compromised or sourced from a third party, an attacker gains access to all repository secrets. Instead, explicitly pass only the secrets that the called workflow requires using the `secrets:` map, e.g. `secrets: { MY_SECRET: ${{ secrets.MY_SECRET }} }`.

secrets: inherit

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/workflows/smoke-test.yml line 238
Likely real: Yes, 87% confidence

This workflow uses `secrets: inherit` to pass all of the calling workflow's secrets to a reusable workflow. This violates the principle of least privilege because the called workflow receives access to every secret in the repository, not just the ones it needs. If the called workflow is compromised or sourced from a third party, an attacker gains access to all repository secrets. Instead, explicitly pass only the secrets that the called workflow requires using the `secrets:` map, e.g. `secrets: { MY_SECRET: ${{ secrets.MY_SECRET }} }`.

secrets: inherit

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/workflows/lint.yml line 51
Likely real: Yes, 57% confidence

Using variable interpolation `${{...}}` with `github` context data in a `run:` step could allow an attacker to inject their own code into the runner. This would allow them to steal secrets and code. `github` context data can have arbitrary user input and should be treated as untrusted. Instead, use an intermediate environment variable with `env:` to store the data and use the environment variable in the `run:` script. Be sure to use double-quotes the environment variable, like this: "$ENVVAR".

run: |
          TEST_ALL=false
          # Check if Release PR
          if [[ "${{ github.event_name }}" == "pull_request" ]]; then
            BRANCH_NAME="$HEAD_REF"
            if [[ "$BRANCH_NAME" =~ ^release-please-- ]]; then
              TEST_ALL=true
              echo "🔔 Detected Release PR - will lint all plugins"
            fi
          # Check if push to main
          elif [[ "${{ github.event_name }}" == "push" && "${{ github.ref }}" == "refs/heads/main" ]]; then
            TEST_ALL=true
            echo "Push to main - will lint all plugins"
          fi
          echo "test_all=$TEST_ALL" >> $GITHUB_OUTPUT

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/workflows/integration-tests-reusable.yml line 228
Likely real: Yes, 57% confidence

Using variable interpolation `${{...}}` with `github` context data in a `run:` step could allow an attacker to inject their own code into the runner. This would allow them to steal secrets and code. `github` context data can have arbitrary user input and should be treated as untrusted. Instead, use an intermediate environment variable with `env:` to store the data and use the environment variable in the `run:` script. Be sure to use double-quotes the environment variable, like this: "$ENVVAR".

run: |
          echo "Activating theme: ${{ inputs.theme }}"
          npm run wp-env run tests-cli -- wp theme activate ${{ inputs.theme }}
          npm run wp-env run tests-cli -- wp theme list

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/workflows/integration-tests-reusable.yml line 245
Likely real: Yes, 57% confidence

Using variable interpolation `${{...}}` with `github` context data in a `run:` step could allow an attacker to inject their own code into the runner. This would allow them to steal secrets and code. `github` context data can have arbitrary user input and should be treated as untrusted. Instead, use an intermediate environment variable with `env:` to store the data and use the environment variable in the `run:` script. Be sure to use double-quotes the environment variable, like this: "$ENVVAR".

run: |
          echo "Installing ACF plugins based on configuration..."
          echo "  INPUT_ACF_PRO=$INPUT_ACF_PRO INPUT_ACF_EXTENDED=$INPUT_ACF_EXTENDED INPUT_ACF_EXTENDED_PRO=$INPUT_ACF_EXTENDED_PRO"
          
          # Determine ACF plugin slug based on Pro/Free
          ACF_PLUGIN_SLUG="advanced-custom-fields/acf.php"
          if [ "$INPUT_ACF_PRO" = "true" ] && [ -n "$ACF_LICENSE_KEY" ] && [ "$ACF_LICENSE_KEY" != "" ]; then
            echo "Installing ACF Pro..."
            ACF_VERSION_PARAM=""
            if [ -n "${{ inputs.acf_version }}" ] && [ "${{ inputs.acf_version }}" != "" ]; then
              ACF_VERSION_PARAM="&t=${{ inputs.acf_version }}"
            fi
            npm run wp-env run tests-cli -- wp plugin install "https://connect.advancedcustomfields.com/v2/plugins/download?p=pro&k=${ACF_LICENSE_KEY}${ACF_VERSION_PARAM}" --activate --quiet --allow-root
            echo "Activating ACF Pro license..."
            npm run wp-env run tests-cli -- wp eval 'if ( function_exists( "acf_pro_activate_license" ) ) { acf_pro_activate_license( "'"${ACF_LICENSE_KEY}"'" ); } elseif ( function_exists( "acf_pro_update_license" ) ) { acf_pro_update_license( "'"${ACF_LICENSE_KEY}"'" ); }' 2>/dev/null || true
            ACF_PLUGIN_SLUG="advanced-custom-fields-pro/acf.php"
          elif [ "$INPUT_ACF_PRO" = "true" ] || [ "$INPUT_ACF_EXTENDED" = "true" ] || [ "${{ inputs.wpgraphql_content_blocks }}" == "true" ] || [ "$INPUT_PLUGIN_NAME" = "wp-graphql-acf" ]; then
            echo "Installing ACF Free..."
            if [ -n "${{ inputs.acf_version }}" ] && [ "${{ inputs.acf_version }}" != "" ]; then
              npm run wp-env run tests-cli -- wp plugin install advanced-custom-fields --version=${{ inputs.acf_version }} --activate --allow-root
            else
              npm run wp-env run tests-cli -- wp plugin install advanced-custom-fields --activate --allow-root
            fi
          fi
          
          # Install ACF Extended only when explicitly requested (respects matrix acf_extended flag)
          # Auto-match version: If ACF Pro is installed, try to install ACF Extended Pro (if license key available)
          # Otherwise install ACF Extended Free
          # Use PHP to parse JSON (PHP is available in WordPress containers, more reliable than jq)
          ACF_EXTENDED_PLUGIN_SLUG=""
          if [ "$INPUT_ACF_EXTENDED" = "true" ]; then
            # If ACF Pro is installed, automatically try ACF Extended Pro (if license key available)
            # This matches the behavior of the local install-acf.sh script
            if [ "$INPUT_ACF_PRO" = "true" ] && [ -n "$ACF_EXTENDED_LICENSE_KEY" ] && [ "$ACF_EXTENDED_LICENSE_KEY" != "" ]; then
              echo "Installing ACF Extended Pro (matching ACF Pro)..."
              # Use PHP to parse JSON instead of jq (PHP is available in WordPress containers)
              INSTALL_RESULT=$(npm run wp-env run tests-cli -- bash -c "
                download_link=\$(curl -s --location --request GET 'https://acf-extended.com?edd_action=get_version&license=${ACF_EXTENDED_LICENSE_KEY}&item_name=ACF%20Extended%20Pro&url=https://acf.wpgraphql.com' | php -r 'echo json_decode(file_get_contents(\"php://stdin\"), true)[\"download_link\"] ?? \"\";');
                download_link=\${download_link%\\\"};
                download_link=\${download_link#\\\"};
                if [ -z \"\$download_link\" ] || [ \"\$download_link\" == \"null\" ] || [ \"\$download_link\" == \"false\" ]; then
                  echo 'ERROR: Invalid license key or download link';
                  exit 1;
                fi;
                wp plugin install \"\$download_link\" --activate --quiet --allow-root;
                echo 'SUCCESS'
              " 2>&1)
              
              if echo "$INSTALL_RESULT" | grep -q "SUCCESS"; then
                ACF_EXTENDED_PLUGIN_SLUG="acf-extended-pro/acf-extended.php"
              elif echo "$INSTALL_RESULT" | grep -q "ERROR: Invalid license key"; then
                echo "⚠️  Warning: ACF Extended Pro license key appears invalid or expired"
                echo "   Falling back to ACF Extended Free..."
                npm run wp-env run tests-cli -- wp plugin install acf-extended --activate --allow-root
                ACF_EXTENDED_PLUGIN_SLUG="acf-extended/acf-extended.php"
              else
                echo "⚠️  Warning: Failed to install ACF Extended Pro"
                echo "   Error: $INSTALL_RESULT"
                echo "   Falling back to ACF Extended Free..."
                npm run wp-env run tests-cli -- wp plugin install acf-extended --activate --allow-root
                ACF_EXTENDED_PLUGIN_SLUG="acf-extended/acf-extended.php"
              fi
            # Explicit request for ACF Extended Pro (even with ACF Free) - respect the flag
            elif [ "$INPUT_ACF_EXTENDED_PRO" = "true" ] && [ -n "$ACF_EXTENDED_LICENSE_KEY" ] && [ "$ACF_EXTENDED_LICENSE_KEY" != "" ]; then
              echo "Installing ACF Extended Pro (explicit request)..."
              # Use PHP to parse JSON instead of jq (PHP is available in WordPress containers)
              INSTALL_RESULT=$(npm run wp-env run tests-cli -- bash -c "
                download_link=\$(curl -s --location --request GET 'https://acf-extended.com?edd_action=get_version&license=${ACF_EXTENDED_LICENSE_KEY}&item_name=ACF%20Extended%20Pro&url=https://acf.wpgraphql.com' | php -r 'echo json_decode(file_get_contents(\"php://stdin\"), true)[\"download_link\"] ?? \"\";');
                download_link=\${download_link%\\\"};
                download_link=\${download_link#\\\"};
                if [ -z \"\$download_link\" ] || [ \"\$download_link\" == \"null\" ] || [ \"\$download_link\" == \"false\" ]; then
                  echo 'ERROR: Invalid license key or download link';
                  exit 1;
                fi;
                wp plugin install \"\$download_link\" --activate --quiet --allow-root;
                echo 'SUCCESS'
              " 2>&1)
              
              if echo "$INSTALL_RESULT" | grep -q "SUCCESS"; then
                ACF_EXTENDED_PLUGIN_SLUG="acf-extended-pro/acf-extended.php"
              elif echo "$INSTALL_RESULT" | grep -q "ERROR: Invalid license key"; then
                echo "⚠️  Warning: ACF Extended Pro license key appears invalid or expired"
                echo "   Falling back to ACF Extended Free..."
                npm run wp-env run tests-cli -- wp plugin install acf-extended --activate --allow-root
                ACF_EXTENDED_PLUGIN_SLUG="acf-extended/acf-extended.php"
              else
                echo "⚠️  Warning: Failed to install ACF Extended Pro"
                echo "   Error: $INSTALL_RESULT"
                echo "   Falling back to ACF Extended Free..."
                npm run wp-env run tests-cli -- wp plugin install acf-extended --activate --allow-root
                ACF_EXTENDED_PLUGIN_SLUG="acf-extended/acf-extended.php"
              fi
            else
              echo "Installing ACF Extended Free..."
              npm run wp-env run tests-cli -- wp plugin install acf-extended --activate --allow-root
              ACF_EXTENDED_PLUGIN_SLUG="acf-extended/acf-extended.php"
            fi
          fi
          
          # Install WPGraphQL Content Blocks if requested
          if [ "${{ inputs.wpgraphql_content_blocks }}" = "true" ]; then
            echo "Installing WPGraphQL Content Blocks..."
            # Fetch latest tag from GitHub API on the runner to avoid wp-env stdout mixing with the version string
            CONTENT_BLOCKS_VERSION=$(curl -s --location --request GET 'https://api.github.com/repos/wpengine/wp-graphql-content-blocks/releases/latest' | jq -r '.tag_name // empty')
            if [ -z "$CONTENT_BLOCKS_VERSION" ]; then
              echo "::error::Failed to resolve WPGraphQL Content Blocks latest release tag"
              exit 1
            fi
            npm run wp-env run tests-cli -- wp plugin install "https://github.com/wpengine/wp-graphql-content-blocks/releases/download/${CONTENT_BLOCKS_VERSION}/wp-graphql-content-blocks.zip" --activate --allow-root
          fi
          
          # Set environment variables for test scripts
          echo "ACF_PLUGIN_SLUG=${ACF_PLUGIN_SLUG}" >> $GITHUB_ENV
          echo "ACF_EXTENDED_PLUGIN_SLUG=${ACF_EXTENDED_PLUGIN_SLUG}" >> $GITHUB_ENV
          
          # List installed plugins for verification
          echo "Installed plugins:"
          npm run wp-env run tests-cli -- wp plugin list --allow-root

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/workflows/integration-tests-reusable.yml line 384
Likely real: Yes, 57% confidence

Using variable interpolation `${{...}}` with `github` context data in a `run:` step could allow an attacker to inject their own code into the runner. This would allow them to steal secrets and code. `github` context data can have arbitrary user input and should be treated as untrusted. Instead, use an intermediate environment variable with `env:` to store the data and use the environment variable in the `run:` script. Be sure to use double-quotes the environment variable, like this: "$ENVVAR".

run: |
          npm run -w @wpgraphql/${{ inputs.plugin_name }} test:codecept:acceptance -- ${{ secrets.ACTIONS_STEP_DEBUG && '--debug' || '' }} ${{ inputs.coverage && github.actor != 'dependabot[bot]' && '--coverage --coverage-xml' || '' }}

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/workflows/integration-tests-reusable.yml line 389
Likely real: Yes, 57% confidence

Using variable interpolation `${{...}}` with `github` context data in a `run:` step could allow an attacker to inject their own code into the runner. This would allow them to steal secrets and code. `github` context data can have arbitrary user input and should be treated as untrusted. Instead, use an intermediate environment variable with `env:` to store the data and use the environment variable in the `run:` script. Be sure to use double-quotes the environment variable, like this: "$ENVVAR".

run: |
          npm run -w @wpgraphql/${{ inputs.plugin_name }} test:codecept:functional -- ${{ secrets.ACTIONS_STEP_DEBUG && '--debug' || '' }}

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/workflows/integration-tests-reusable.yml line 407
Likely real: Yes, 57% confidence

Using variable interpolation `${{...}}` with `github` context data in a `run:` step could allow an attacker to inject their own code into the runner. This would allow them to steal secrets and code. `github` context data can have arbitrary user input and should be treated as untrusted. Instead, use an intermediate environment variable with `env:` to store the data and use the environment variable in the `run:` script. Be sure to use double-quotes the environment variable, like this: "$ENVVAR".

run: |
          npm run wp-env -- run tests-cli --env-cwd=wp-content/plugins/${{ inputs.plugin_name }}/ -- bash -c 'export TEST_DB_HOST=${WORDPRESS_DB_HOST:-tests-mysql} TEST_DB_NAME=${WORDPRESS_DB_NAME:-tests-wordpress} TEST_DB_USER=${WORDPRESS_DB_USER:-root} TEST_DB_PASSWORD=${WORDPRESS_DB_PASSWORD:-password} TEST_WP_TABLE_PREFIX=${TEST_WP_TABLE_PREFIX:-wp_} TEST_WP_DOMAIN=${TEST_WP_DOMAIN:-localhost} TEST_ADMIN_EMAIL=${TEST_ADMIN_EMAIL:-admin@example.org} TEST_WP_ROOT_FOLDER=${TEST_WP_ROOT_FOLDER:-/var/www/html} MULTISITE=${{ inputs.multisite && 'true' || 'false' }} TEST_THEME=${{ inputs.theme }} && vendor/bin/codecept run wpunit ${{ secrets.ACTIONS_STEP_DEBUG && '--debug' || '' }} ${{ inputs.coverage && github.actor != 'dependabot[bot]' && '--coverage --coverage-xml' || '' }}'

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/workflows/integration-tests-reusable.yml line 419
Likely real: Yes, 57% confidence

Using variable interpolation `${{...}}` with `github` context data in a `run:` step could allow an attacker to inject their own code into the runner. This would allow them to steal secrets and code. `github` context data can have arbitrary user input and should be treated as untrusted. Instead, use an intermediate environment variable with `env:` to store the data and use the environment variable in the `run:` script. Be sure to use double-quotes the environment variable, like this: "$ENVVAR".

run: |
          npm run -w @wpgraphql/${{ inputs.plugin_name }} test:codecept:wpunit-integration -- ${{ secrets.ACTIONS_STEP_DEBUG && '--debug' || '' }}

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/workflows/integration-tests-reusable.yml line 440
Likely real: Yes, 57% confidence

Using variable interpolation `${{...}}` with `github` context data in a `run:` step could allow an attacker to inject their own code into the runner. This would allow them to steal secrets and code. `github` context data can have arbitrary user input and should be treated as untrusted. Instead, use an intermediate environment variable with `env:` to store the data and use the environment variable in the `run:` script. Be sure to use double-quotes the environment variable, like this: "$ENVVAR".

run: |
          if [ ! -f "${{ inputs.plugin_path }}/tests/_output/coverage.xml" ]; then
            echo "❌ Coverage file not found!"
            exit 1
          fi
          echo "✅ Coverage file exists: ${{ inputs.plugin_path }}/tests/_output/coverage.xml"
          echo "File size: $(wc -c < "${{ inputs.plugin_path }}/tests/_output/coverage.xml") bytes"

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/workflows/upload-schema-artifact.yml line 88
Likely real: Yes, 57% confidence

Using variable interpolation `${{...}}` with `github` context data in a `run:` step could allow an attacker to inject their own code into the runner. This would allow them to steal secrets and code. `github` context data can have arbitrary user input and should be treated as untrusted. Instead, use an intermediate environment variable with `env:` to store the data and use the environment variable in the `run:` script. Be sure to use double-quotes the environment variable, like this: "$ENVVAR".

run: |
          TAG="${{ inputs.tag || github.event.release.tag_name }}"
          # Tags are component-scoped (e.g. wp-graphql/v2.16.0 -> component wp-graphql).
          if [[ "$TAG" == */* ]]; then
            COMPONENT="${TAG%%/*}"
          else
            COMPONENT="wp-graphql"
          fi
          # Required plugins = wp-graphql (always — registers the CLI command + is the base
          # dependency) plus the component itself. Mirrors schema-linter.yml's active_plugins.
          REQUIRED="wp-graphql"
          if [[ "$COMPONENT" != "wp-graphql" ]]; then
            REQUIRED="wp-graphql $COMPONENT"
          fi
          echo "component=$COMPONENT" >> "$GITHUB_OUTPUT"
          echo "required_plugins=$REQUIRED" >> "$GITHUB_OUTPUT"
          echo "Releasing component: $COMPONENT | required plugins: $REQUIRED"

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/workflows/smoke-test.yml line 74
Likely real: Yes, 57% confidence

Using variable interpolation `${{...}}` with `github` context data in a `run:` step could allow an attacker to inject their own code into the runner. This would allow them to steal secrets and code. `github` context data can have arbitrary user input and should be treated as untrusted. Instead, use an intermediate environment variable with `env:` to store the data and use the environment variable in the `run:` script. Be sure to use double-quotes the environment variable, like this: "$ENVVAR".

run: |
          TEST_ALL=false
          # Check if Release PR
          if [[ "${{ github.event_name }}" == "pull_request" ]]; then
            BRANCH_NAME="$HEAD_REF"
            if [[ "$BRANCH_NAME" =~ ^release-please-- ]]; then
              TEST_ALL=true
              echo "🔔 Detected Release PR - will smoke test all plugins"
            fi
          # Check if push to main
          elif [[ "${{ github.event_name }}" == "push" && "${{ github.ref }}" == "refs/heads/main" ]]; then
            TEST_ALL=true
            echo "Push to main - will smoke test all plugins"
          fi
          echo "test_all=$TEST_ALL" >> $GITHUB_OUTPUT

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/workflows/smoke-test-reusable.yml line 242
Likely real: Yes, 57% confidence

Using variable interpolation `${{...}}` with `github` context data in a `run:` step could allow an attacker to inject their own code into the runner. This would allow them to steal secrets and code. `github` context data can have arbitrary user input and should be treated as untrusted. Instead, use an intermediate environment variable with `env:` to store the data and use the environment variable in the `run:` script. Be sure to use double-quotes the environment variable, like this: "$ENVVAR".

run: |
          # Run smoke tests against the WordPress container
          if [ -f "${{ inputs.smoke_test_script }}" ]; then
            ${{ inputs.smoke_test_script }} --verbose
          else
            echo "⚠️ Smoke test script not found: ${{ inputs.smoke_test_script }}"
            echo "Skipping smoke tests for this plugin."
          fi

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/workflows/smoke-test-reusable.yml line 235
Likely real: Yes, 57% confidence

Using variable interpolation `${{...}}` with `github` context data in a `run:` step could allow an attacker to inject their own code into the runner. This would allow them to steal secrets and code. `github` context data can have arbitrary user input and should be treated as untrusted. Instead, use an intermediate environment variable with `env:` to store the data and use the environment variable in the `run:` script. Be sure to use double-quotes the environment variable, like this: "$ENVVAR".

run: |
          echo "📦 Installed plugins:"
          npm run wp-env -- run cli wp plugin list
          echo ""
          npm run wp-env -- run cli wp plugin is-active ${{ inputs.plugin_slug }}

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/workflows/smoke-test-reusable.yml line 197
Likely real: Yes, 57% confidence

Using variable interpolation `${{...}}` with `github` context data in a `run:` step could allow an attacker to inject their own code into the runner. This would allow them to steal secrets and code. `github` context data can have arbitrary user input and should be treated as untrusted. Instead, use an intermediate environment variable with `env:` to store the data and use the environment variable in the `run:` script. Be sure to use double-quotes the environment variable, like this: "$ENVVAR".

run: |
          # Find the zip file location
          ZIP_PATH="plugin-build/${{ inputs.zip_name }}"
          if [ ! -f "$ZIP_PATH" ]; then
            ZIP_PATH="${{ inputs.plugin_path }}/plugin-build/${{ inputs.zip_name }}"
          fi

          echo "📦 Copying zip to container..."
          CONTAINER_NAME=$(docker ps --format '{{.Names}}' | grep 'cli-1' | grep -v 'tests' | head -1)
          docker cp "$ZIP_PATH" "$CONTAINER_NAME":/tmp/${{ inputs.zip_name }}

          # Install wp-graphql first if required
          if [ "${{ inputs.requires_wp_graphql }}" = "true" ]; then
            echo "📦 Installing wp-graphql first (required dependency)..."
            # Check if wp-graphql zip exists, if not we'll need to build it or skip
            if [ -f "plugin-build/wp-graphql.zip" ]; then
              docker cp plugin-build/wp-graphql.zip "$CONTAINER_NAME":/tmp/wp-graphql.zip
              npm run wp-env -- run cli wp plugin install /tmp/wp-graphql.zip --activate
            else
              echo "⚠️ Warning: wp-graphql.zip not found. This plugin requires wp-graphql to be active."
              echo "For now, we'll try to install the plugin and see if wp-graphql is available."
            fi
          fi

          echo "📦 Installing ${{ inputs.plugin_name }} from zip..."
          npm run wp-env -- run cli wp plugin install /tmp/${{ inputs.zip_name }} --activate

          echo "🔄 Flushing permalinks..."
          npm run wp-env -- run cli wp rewrite structure '/%postname%/' --hard
          npm run wp-env -- run cli wp rewrite flush --hard

          # Only enable GraphQL settings if wp-graphql is active
          if npm run wp-env -- run cli wp plugin is-active wp-graphql 2>/dev/null; then
            echo "⚙️ Enabling public introspection..."
            npm run wp-env -- run cli wp option update graphql_general_settings '{"graphql_endpoint":"graphql","public_introspection_enabled":"on"}' --format=json
          fi

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/workflows/smoke-test-reusable.yml line 124
Likely real: Yes, 57% confidence

Using variable interpolation `${{...}}` with `github` context data in a `run:` step could allow an attacker to inject their own code into the runner. This would allow them to steal secrets and code. `github` context data can have arbitrary user input and should be treated as untrusted. Instead, use an intermediate environment variable with `env:` to store the data and use the environment variable in the `run:` script. Be sure to use double-quotes the environment variable, like this: "$ENVVAR".

run: |
          echo "📦 Verifying zip was created..."
          ls -la plugin-build/ || ls -la ${{ inputs.plugin_path }}/plugin-build/
          echo ""
          echo "📋 Zip contents:"
          ZIP_PATH="plugin-build/${{ inputs.zip_name }}"
          if [ ! -f "$ZIP_PATH" ]; then
            ZIP_PATH="${{ inputs.plugin_path }}/plugin-build/${{ inputs.zip_name }}"
          fi
          unzip -l "$ZIP_PATH" | head -50

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/workflows/schema-linter.yml line 51
Likely real: Yes, 57% confidence

Using variable interpolation `${{...}}` with `github` context data in a `run:` step could allow an attacker to inject their own code into the runner. This would allow them to steal secrets and code. `github` context data can have arbitrary user input and should be treated as untrusted. Instead, use an intermediate environment variable with `env:` to store the data and use the environment variable in the `run:` script. Be sure to use double-quotes the environment variable, like this: "$ENVVAR".

run: |
          TEST_ALL=false
          # Check if Release PR
          if [[ "${{ github.event_name }}" == "pull_request" ]]; then
            BRANCH_NAME="$HEAD_REF"
            if [[ "$BRANCH_NAME" =~ ^release-please-- ]]; then
              TEST_ALL=true
              echo "🔔 Detected Release PR - will schema lint all plugins"
            fi
          # Check if push to main
          elif [[ "${{ github.event_name }}" == "push" && "${{ github.ref }}" == "refs/heads/main" ]]; then
            TEST_ALL=true
            echo "Push to main - will schema lint all plugins"
          fi
          echo "test_all=$TEST_ALL" >> $GITHUB_OUTPUT

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/workflows/schema-linter-reusable.yml line 279
Likely real: Yes, 57% confidence

Using variable interpolation `${{...}}` with `github` context data in a `run:` step could allow an attacker to inject their own code into the runner. This would allow them to steal secrets and code. `github` context data can have arbitrary user input and should be treated as untrusted. Instead, use an intermediate environment variable with `env:` to store the data and use the environment variable in the `run:` script. Be sure to use double-quotes the environment variable, like this: "$ENVVAR".

run: |
          if [ "${{ steps.get-latest-tag.outputs.tag_found }}" != "true" ]; then
            echo "::notice::Schema comparison was skipped because no tags were found for component ${{ inputs.component }}."
            echo "This is expected for plugins that haven't been released yet."
          else
            echo "::notice::Schema comparison was skipped because the previous release (${{ steps.get-latest-tag.outputs.tag }}) does not have a schema.graphql artifact."
            echo "This is expected for the first release after enabling schema artifact uploads."
          fi

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/workflows/schema-linter-reusable.yml line 273
Likely real: Yes, 57% confidence

Using variable interpolation `${{...}}` with `github` context data in a `run:` step could allow an attacker to inject their own code into the runner. This would allow them to steal secrets and code. `github` context data can have arbitrary user input and should be treated as untrusted. Instead, use an intermediate environment variable with `env:` to store the data and use the environment variable in the `run:` script. Be sure to use double-quotes the environment variable, like this: "$ENVVAR".

run: |
          # This schema and previous release schema
          node_modules/.bin/graphql-inspector diff /tmp/${{ steps.get-previous-schema.outputs.safe_tag }}.graphql /tmp/schema-${{ inputs.component }}.graphql

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/workflows/schema-linter-reusable.yml line 209
Likely real: Yes, 57% confidence

Using variable interpolation `${{...}}` with `github` context data in a `run:` step could allow an attacker to inject their own code into the runner. This would allow them to steal secrets and code. `github` context data can have arbitrary user input and should be treated as untrusted. Instead, use an intermediate environment variable with `env:` to store the data and use the environment variable in the `run:` script. Be sure to use double-quotes the environment variable, like this: "$ENVVAR".

run: |
          # Get the latest tag for this specific component
          # Tags are formatted as: {component}/{version} (e.g., wp-graphql/v2.7.0)
          COMPONENT="${{ inputs.component }}"
          echo "Looking for latest tag with prefix: $COMPONENT/"

          # Fetch all tags from remote and filter by component prefix
          git fetch origin --tags --force
          LATEST_TAG=$(git tag -l "$COMPONENT/v*" | sort -V | tail -1)

          if [ -z "$LATEST_TAG" ]; then
            echo "::warning::No tags found for component $COMPONENT. Schema comparison will be skipped."
            echo "tag=" >> $GITHUB_OUTPUT
            echo "tag_found=false" >> $GITHUB_OUTPUT
          else
            echo "Found latest tag: $LATEST_TAG"
            echo "tag=$LATEST_TAG" >> $GITHUB_OUTPUT
            echo "tag_found=true" >> $GITHUB_OUTPUT
          fi

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/workflows/schema-linter-reusable.yml line 204
Likely real: Yes, 57% confidence

Using variable interpolation `${{...}}` with `github` context data in a `run:` step could allow an attacker to inject their own code into the runner. This would allow them to steal secrets and code. `github` context data can have arbitrary user input and should be treated as untrusted. Instead, use an intermediate environment variable with `env:` to store the data and use the environment variable in the `run:` script. Be sure to use double-quotes the environment variable, like this: "$ENVVAR".

run: |
          graphql-schema-linter /tmp/schema-${{ inputs.component }}.graphql || true

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/workflows/schema-linter-reusable.yml line 200
Likely real: Yes, 57% confidence

Using variable interpolation `${{...}}` with `github` context data in a `run:` step could allow an attacker to inject their own code into the runner. This would allow them to steal secrets and code. `github` context data can have arbitrary user input and should be treated as untrusted. Instead, use an intermediate environment variable with `env:` to store the data and use the environment variable in the `run:` script. Be sure to use double-quotes the environment variable, like this: "$ENVVAR".

run: |
          graphql-schema-linter --except=relay-connection-types-spec,relay-page-info-spec --ignore '{"defined-types-are-used":["MenuItemsWhereArgs","TermObjectUnion","TimezoneEnum"]}' /tmp/schema-${{ inputs.component }}.graphql

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/workflows/schema-linter-reusable.yml line 188
Likely real: Yes, 57% confidence

Using variable interpolation `${{...}}` with `github` context data in a `run:` step could allow an attacker to inject their own code into the runner. This would allow them to steal secrets and code. `github` context data can have arbitrary user input and should be treated as untrusted. Instead, use an intermediate environment variable with `env:` to store the data and use the environment variable in the `run:` script. Be sure to use double-quotes the environment variable, like this: "$ENVVAR".

run: |
          npm run wp-env run cli -- wp graphql generate-static-schema --output=/var/www/html/schema.graphql
          # Copy schema out of container using docker cp
          echo "Available containers:"
          docker ps --format '{{.Names}}'
          # Find the WordPress cli container (contains 'cli' but not 'tests')
          CONTAINER_ID=$(docker ps --format '{{.Names}}' | grep 'cli' | grep -v 'tests' | head -1)
          echo "Using container: $CONTAINER_ID"
          docker cp "$CONTAINER_ID:/var/www/html/schema.graphql" /tmp/schema-${{ inputs.component }}.graphql
          echo "Schema generated: $(wc -l < /tmp/schema-${{ inputs.component }}.graphql) lines"

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/workflows/schema-linter-reusable.yml line 105
Likely real: Yes, 57% confidence

Using variable interpolation `${{...}}` with `github` context data in a `run:` step could allow an attacker to inject their own code into the runner. This would allow them to steal secrets and code. `github` context data can have arbitrary user input and should be treated as untrusted. Instead, use an intermediate environment variable with `env:` to store the data and use the environment variable in the `run:` script. Be sure to use double-quotes the environment variable, like this: "$ENVVAR".

run: |
          # setup-wp-env.sh (via afterStart) already activates wp-graphql in the cli container,
          # which registers the CLI command. We MUST NOT deactivate wp-graphql or the CLI
          # command will be lost. Instead, we deactivate only other plugins, then activate
          # the target plugin(s) if needed.

          echo "Current plugin status (before configuration):"
          npm run wp-env run cli -- wp plugin list --status=active

          # Determine which plugins should be active for this component
          REQUIRED_PLUGINS="wp-graphql"
          if [ -n "${{ inputs.active_plugins }}" ]; then
            # Add any additional plugins specified in active_plugins
            for plugin in $(echo "${{ inputs.active_plugins }}" | tr ',' ' '); do
              if [ "$plugin" != "wp-graphql" ]; then
                REQUIRED_PLUGINS="$REQUIRED_PLUGINS $plugin"
              fi
            done
          fi

          echo "Required plugins for schema generation: $REQUIRED_PLUGINS"

          # Get list of currently active plugins (excluding wp-graphql)
          # Parse the tabular output and extract just the plugin names from the first column
          # Skip header line (NR>1) and filter out wp-graphql
          ACTIVE_PLUGINS=$(npm run wp-env run cli -- wp plugin list --status=active 2>/dev/null | awk 'NR>1 {print $1}' | grep -v "^wp-graphql$" || true)

          # Deactivate plugins that shouldn't be active (but keep wp-graphql active!)
          echo "Deactivating unnecessary plugins (keeping wp-graphql active)..."
          if [ -n "$ACTIVE_PLUGINS" ]; then
            for plugin in $ACTIVE_PLUGINS; do
              # Skip empty lines and non-plugin strings
              if [ -z "$plugin" ] || [ "$plugin" = "name" ] || [ "$plugin" = "status" ]; then
                continue
              fi
              
              # Check if this plugin should be kept active
              KEEP_PLUGIN=false
              for required in $REQUIRED_PLUGINS; do
                if [ "$plugin" = "$required" ]; then
                  KEEP_PLUGIN=true
                  break
                fi
              done
              
              if [ "$KEEP_PLUGIN" = "false" ]; then
                echo "Deactivating: $plugin"
                npm run wp-env run cli -- wp plugin deactivate "$plugin" 2>/dev/null || true
              fi
            done
          fi

          # Activate any required plugins that aren't already active
          for plugin in $REQUIRED_PLUGINS; do
            if [ "$plugin" != "wp-graphql" ]; then
              echo "Ensuring plugin is active: $plugin"
              npm run wp-env run cli -- wp plugin activate "$plugin" 2>/dev/null || echo "Warning: Could not activate $plugin"
            fi
          done

          # Show final active plugins (should only be wp-graphql + target plugin)
          echo "Active plugins for schema generation:"
          npm run wp-env run cli -- wp plugin list --status=active

          # Verify wp-graphql CLI command is available (critical for schema generation)
          # The WPGraphQL plugin should automatically register the CLI command when it loads
          echo "Verifying wp graphql CLI command is registered..."
          if npm run wp-env run cli -- wp help graphql 2>&1 | grep -q "generate-static-schema"; then
            echo "✅ wp graphql CLI command is available"
          else
            echo "❌ wp graphql CLI command NOT found"
            echo "This may indicate a problem with wp-graphql plugin loading or CLI command registration."
            echo "Debug: Checking wp-graphql plugin status..."
            npm run wp-env run cli -- wp plugin list | grep wp-graphql || echo "wp-graphql plugin not found"
            echo "Debug: Available wp commands:"
            npm run wp-env run cli -- wp help 2>&1 | grep -E "^  [a-z]" | head -10
            exit 1
          fi

          # Flush rewrite rules to ensure GraphQL endpoint is registered
          npm run wp-env run cli -- wp rewrite flush 2>/dev/null || true

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/workflows/schema-linter-reusable.yml line 58
Likely real: Yes, 57% confidence

Using variable interpolation `${{...}}` with `github` context data in a `run:` step could allow an attacker to inject their own code into the runner. This would allow them to steal secrets and code. `github` context data can have arbitrary user input and should be treated as untrusted. Instead, use an intermediate environment variable with `env:` to store the data and use the environment variable in the `run:` script. Be sure to use double-quotes the environment variable, like this: "$ENVVAR".

run: |
          echo "Verifying vendor directories..."
          if [ "${{ inputs.component }}" != "wp-graphql" ]; then
            test -f plugins/wp-graphql/vendor/autoload.php && echo "✅ wp-graphql vendor/autoload.php exists" || echo "❌ wp-graphql vendor/autoload.php missing"
          fi
          test -f ${{ inputs.composer_working_dir }}/vendor/autoload.php && echo "✅ ${{ inputs.component }} vendor/autoload.php exists" || echo "❌ ${{ inputs.component }} vendor/autoload.php missing"

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/workflows/js-e2e-tests-reusable.yml line 113
Likely real: Yes, 57% confidence

Using variable interpolation `${{...}}` with `github` context data in a `run:` step could allow an attacker to inject their own code into the runner. This would allow them to steal secrets and code. `github` context data can have arbitrary user input and should be treated as untrusted. Instead, use an intermediate environment variable with `env:` to store the data and use the environment variable in the `run:` script. Be sure to use double-quotes the environment variable, like this: "$ENVVAR".

run: |
          echo "📦 Building wp-graphql (required dependency for ${{ inputs.plugin_name }})..."
          npm run build -w @wpgraphql/wp-graphql
          echo "✅ wp-graphql built successfully"

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/workflows/integration-tests-reusable.yml line 433
Likely real: Yes, 57% confidence

Using variable interpolation `${{...}}` with `github` context data in a `run:` step could allow an attacker to inject their own code into the runner. This would allow them to steal secrets and code. `github` context data can have arbitrary user input and should be treated as untrusted. Instead, use an intermediate environment variable with `env:` to store the data and use the environment variable in the `run:` script. Be sure to use double-quotes the environment variable, like this: "$ENVVAR".

run: |
          # Map Docker container paths to repo-relative paths for Codecov
          sed -i "s|/var/www/html/wp-content/plugins/${{ inputs.plugin_name }}/|${{ inputs.plugin_path }}/|g" ${{ inputs.plugin_path }}/tests/_output/coverage.xml

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/workflows/integration-tests-reusable.yml line 190
Likely real: Yes, 57% confidence

Using variable interpolation `${{...}}` with `github` context data in a `run:` step could allow an attacker to inject their own code into the runner. This would allow them to steal secrets and code. `github` context data can have arbitrary user input and should be treated as untrusted. Instead, use an intermediate environment variable with `env:` to store the data and use the environment variable in the `run:` script. Be sure to use double-quotes the environment variable, like this: "$ENVVAR".

run: npm run build -- --filter='@wpgraphql/${{ inputs.plugin_name }}...'

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/workflows/js-e2e-tests-reusable.yml line 235
Likely real: Yes, 57% confidence

Using variable interpolation `${{...}}` with `github` context data in a `run:` step could allow an attacker to inject their own code into the runner. This would allow them to steal secrets and code. `github` context data can have arbitrary user input and should be treated as untrusted. Instead, use an intermediate environment variable with `env:` to store the data and use the environment variable in the `run:` script. Be sure to use double-quotes the environment variable, like this: "$ENVVAR".

run: |
          npm run -w @wpgraphql/${{ inputs.plugin_name }} test:e2e

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /websites/wpgraphql.com/src/components/Site/SearchButton.js line 23
Likely real: Yes, 52% confidence

Generic API Key detected

const API_KEY = "0c11d662dad18e8a18d20c969b25c65f"

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /scripts/update-upgrade-notice.js line 61
Likely real: Yes, 100% confidence

RegExp() called with a `version` function argument, this might allow an attacker to cause a Regular Expression Denial-of-Service (ReDoS) within your application as RegExP blocks the main thread. For this reason, it is recommended to use hardcoded regexes instead. If your regex is run on user-controlled input, consider performing input validation or use a regex checking/sanitization library such as https://www.npmjs.com/package/recheck to verify that the regex does not appear vulnerable to ReDoS.

const versionPattern = new RegExp(
		`## \\[?${escapedVersion}\\]?[^\\n]*\\n([\\s\\S]*?)(?=\\n## |$)`,
		'i'
	);

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /scripts/update-upgrade-notice.js line 163
Likely real: Yes, 100% confidence

RegExp() called with a `version` function argument, this might allow an attacker to cause a Regular Expression Denial-of-Service (ReDoS) within your application as RegExP blocks the main thread. For this reason, it is recommended to use hardcoded regexes instead. If your regex is run on user-controlled input, consider performing input validation or use a regex checking/sanitization library such as https://www.npmjs.com/package/recheck to verify that the regex does not appear vulnerable to ReDoS.

const versionNoticeRegex = new RegExp(
			`(^|\\n)= ${escapedVersion} =`
		);

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /scripts/update-upgrade-notice.js line 171
Likely real: Yes, 100% confidence

RegExp() called with a `version` function argument, this might allow an attacker to cause a Regular Expression Denial-of-Service (ReDoS) within your application as RegExP blocks the main thread. For this reason, it is recommended to use hardcoded regexes instead. If your regex is run on user-controlled input, consider performing input validation or use a regex checking/sanitization library such as https://www.npmjs.com/package/recheck to verify that the regex does not appear vulnerable to ReDoS.

const existingNoticeRegex = new RegExp(
				`(^|\\n)= ${escapedVersion} =[\\s\\S]*?(?=\\n= \\d|$)`
			);

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /scripts/update-version-constants.js line 290
Likely real: Yes, 100% confidence

RegExp() called with a `version` function argument, this might allow an attacker to cause a Regular Expression Denial-of-Service (ReDoS) within your application as RegExP blocks the main thread. For this reason, it is recommended to use hardcoded regexes instead. If your regex is run on user-controlled input, consider performing input validation or use a regex checking/sanitization library such as https://www.npmjs.com/package/recheck to verify that the regex does not appear vulnerable to ReDoS.

const versionHeaderRegex = new RegExp(
		`Version:\\s+${version.replace(/\./g, '\\.')}`
	);

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /scripts/update-version-constants.js line 293
Likely real: Yes, 100% confidence

RegExp() called with a `version` function argument, this might allow an attacker to cause a Regular Expression Denial-of-Service (ReDoS) within your application as RegExP blocks the main thread. For this reason, it is recommended to use hardcoded regexes instead. If your regex is run on user-controlled input, consider performing input validation or use a regex checking/sanitization library such as https://www.npmjs.com/package/recheck to verify that the regex does not appear vulnerable to ReDoS.

const versionDocblockRegex = new RegExp(
		`@version\\s+${version.replace(/\./g, '\\.')}`
	);

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /scripts/update-readme-changelog.js line 198
Likely real: Yes, 100% confidence

RegExp() called with a `version` function argument, this might allow an attacker to cause a Regular Expression Denial-of-Service (ReDoS) within your application as RegExP blocks the main thread. For this reason, it is recommended to use hardcoded regexes instead. If your regex is run on user-controlled input, consider performing input validation or use a regex checking/sanitization library such as https://www.npmjs.com/package/recheck to verify that the regex does not appear vulnerable to ReDoS.

const versionPattern = new RegExp(
		`(?<=^|\\n)= ${escapeRegExp(version)} =[\\s\\S]*?(?=\\n= [0-9]+\\.[0-9]+\\.[0-9]+(?:-[\\w.-]+)? =\\s*(?:\\n|$)|\\n== |$)`
	);

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /scripts/hooks/generate-hook-docs.js line 734
Likely real: Yes, 100% confidence

RegExp() called with a `groups` function argument, this might allow an attacker to cause a Regular Expression Denial-of-Service (ReDoS) within your application as RegExP blocks the main thread. For this reason, it is recommended to use hardcoded regexes instead. If your regex is run on user-controlled input, consider performing input validation or use a regex checking/sanitization library such as https://www.npmjs.com/package/recheck to verify that the regex does not appear vulnerable to ReDoS.

const regex = new RegExp(pattern);

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /scripts/hooks/generate-hook-docs.js line 1131
Likely real: Yes, 100% confidence

RegExp() called with a `namingRules` function argument, this might allow an attacker to cause a Regular Expression Denial-of-Service (ReDoS) within your application as RegExP blocks the main thread. For this reason, it is recommended to use hardcoded regexes instead. If your regex is run on user-controlled input, consider performing input validation or use a regex checking/sanitization library such as https://www.npmjs.com/package/recheck to verify that the regex does not appear vulnerable to ReDoS.

namePattern: new RegExp(namingRules.allowedHookNamePattern),

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /scripts/hooks/generate-hook-docs.js line 1132
Likely real: Yes, 100% confidence

RegExp() called with a `namingRules` function argument, this might allow an attacker to cause a Regular Expression Denial-of-Service (ReDoS) within your application as RegExP blocks the main thread. For this reason, it is recommended to use hardcoded regexes instead. If your regex is run on user-controlled input, consider performing input validation or use a regex checking/sanitization library such as https://www.npmjs.com/package/recheck to verify that the regex does not appear vulnerable to ReDoS.

dynamicPattern: new RegExp(namingRules.dynamicNamePattern),

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /websites/wpgraphql.com/src/lib/parse-mdx-docs.ts line 50
Likely real: Yes, 100% confidence

RegExp() called with a `product` function argument, this might allow an attacker to cause a Regular Expression Denial-of-Service (ReDoS) within your application as RegExP blocks the main thread. For this reason, it is recommended to use hardcoded regexes instead. If your regex is run on user-controlled input, consider performing input validation or use a regex checking/sanitization library such as https://www.npmjs.com/package/recheck to verify that the regex does not appear vulnerable to ReDoS.

return new RegExp(`${docsFolderFor(product)}/(?<slug>.*)\\.md(x?)$`, "i")

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /scripts/update-version-constants.js line 161
Likely real: Yes, 100% confidence

RegExp() called with a `constantName` function argument, this might allow an attacker to cause a Regular Expression Denial-of-Service (ReDoS) within your application as RegExP blocks the main thread. For this reason, it is recommended to use hardcoded regexes instead. If your regex is run on user-controlled input, consider performing input validation or use a regex checking/sanitization library such as https://www.npmjs.com/package/recheck to verify that the regex does not appear vulnerable to ReDoS.

const constantExists = new RegExp(
			`define\\s*\\(\\s*['"]${escapedConstant}['"]`,
			'i'
		).test(content);

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /scripts/update-version-constants.js line 144
Likely real: Yes, 100% confidence

RegExp() called with a `constantName` function argument, this might allow an attacker to cause a Regular Expression Denial-of-Service (ReDoS) within your application as RegExP blocks the main thread. For this reason, it is recommended to use hardcoded regexes instead. If your regex is run on user-controlled input, consider performing input validation or use a regex checking/sanitization library such as https://www.npmjs.com/package/recheck to verify that the regex does not appear vulnerable to ReDoS.

const pattern = new RegExp(
		`(\\s*)define\\s*\\(\\s*['"]${escapedConstant}['"]\\s*,\\s*['"]([^'"]*)['"]\\s*\\)\\s*;`,
		'g'
	);

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /plugins/wp-graphql-acf/docker-compose.yml line 51
Likely real: Yes, 100% confidence

Service 'testing_db' is running with a writable root filesystem. This may allow malicious applications to download and run additional payloads, or modify container files. If an application inside a container has to save something temporarily consider using a tmpfs. Add 'read_only: true' to this service to prevent this.

testing_db:

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /plugins/wp-graphql-smart-cache/docker-compose.yml line 4
Likely real: Yes, 100% confidence

Service 'varnish' is running with a writable root filesystem. This may allow malicious applications to download and run additional payloads, or modify container files. If an application inside a container has to save something temporarily consider using a tmpfs. Add 'read_only: true' to this service to prevent this.

varnish:

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /plugins/wp-graphql-smart-cache/docker-compose.yml line 30
Likely real: Yes, 100% confidence

Service 'app_db' is running with a writable root filesystem. This may allow malicious applications to download and run additional payloads, or modify container files. If an application inside a container has to save something temporarily consider using a tmpfs. Add 'read_only: true' to this service to prevent this.

app_db:

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /plugins/wp-graphql-acf/docker-compose.yml line 32
Likely real: Yes, 100% confidence

Service 'testing' is running with a writable root filesystem. This may allow malicious applications to download and run additional payloads, or modify container files. If an application inside a container has to save something temporarily consider using a tmpfs. Add 'read_only: true' to this service to prevent this.

testing:

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /plugins/wp-graphql-acf/docker-compose.yml line 23
Likely real: Yes, 100% confidence

Service 'app_db' is running with a writable root filesystem. This may allow malicious applications to download and run additional payloads, or modify container files. If an application inside a container has to save something temporarily consider using a tmpfs. Add 'read_only: true' to this service to prevent this.

app_db:

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /plugins/wp-graphql-smart-cache/docker-compose.yml line 37
Likely real: Yes, 100% confidence

Service 'testing' is running with a writable root filesystem. This may allow malicious applications to download and run additional payloads, or modify container files. If an application inside a container has to save something temporarily consider using a tmpfs. Add 'read_only: true' to this service to prevent this.

testing:

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /plugins/wp-graphql-smart-cache/docker-compose.yml line 52
Likely real: Yes, 100% confidence

Service 'testing_db' is running with a writable root filesystem. This may allow malicious applications to download and run additional payloads, or modify container files. If an application inside a container has to save something temporarily consider using a tmpfs. Add 'read_only: true' to this service to prevent this.

testing_db:

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /plugins/wp-graphql-acf/docker-compose.yml line 32
Likely real: Yes, 99% confidence

Service 'testing' allows for privilege escalation via setuid or setgid binaries. Add 'no-new-privileges:true' in 'security_opt' to prevent this.

testing:

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /plugins/wp-graphql-acf/docker-compose.yml line 51
Likely real: Yes, 99% confidence

Service 'testing_db' allows for privilege escalation via setuid or setgid binaries. Add 'no-new-privileges:true' in 'security_opt' to prevent this.

testing_db:

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /plugins/wp-graphql-smart-cache/docker-compose.yml line 4
Likely real: Yes, 99% confidence

Service 'varnish' allows for privilege escalation via setuid or setgid binaries. Add 'no-new-privileges:true' in 'security_opt' to prevent this.

varnish:

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /plugins/wp-graphql-smart-cache/docker-compose.yml line 30
Likely real: Yes, 99% confidence

Service 'app_db' allows for privilege escalation via setuid or setgid binaries. Add 'no-new-privileges:true' in 'security_opt' to prevent this.

app_db:

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /plugins/wp-graphql-smart-cache/docker-compose.yml line 37
Likely real: Yes, 99% confidence

Service 'testing' allows for privilege escalation via setuid or setgid binaries. Add 'no-new-privileges:true' in 'security_opt' to prevent this.

testing:

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /plugins/wp-graphql-smart-cache/docker-compose.yml line 52
Likely real: Yes, 99% confidence

Service 'testing_db' allows for privilege escalation via setuid or setgid binaries. Add 'no-new-privileges:true' in 'security_opt' to prevent this.

testing_db:

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /plugins/wp-graphql-acf/docker-compose.yml line 23
Likely real: Yes, 99% confidence

Service 'app_db' allows for privilege escalation via setuid or setgid binaries. Add 'no-new-privileges:true' in 'security_opt' to prevent this.

app_db:

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/dependabot.yml line 161
Likely real: Yes, 99% confidence

This Dependabot configuration does not set a cooldown period. Newly published packages can be malicious or unstable. Add a `cooldown` block with `default-days: 7` to each `package-ecosystem` entry under `updates` to wait 7 days before proposing updates to newly published package versions. Reference: https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#cooldown

- package-ecosystem: 'github-actions'
    directory: '/'
    schedule:
      interval: 'weekly'
    commit-message:
      prefix: 'chore'
      include: 'scope'
    groups:
      github-actions-updates:
        patterns: ['*']

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /plugins/wp-graphql-smart-cache/docker-compose.yml line 14
Likely real: Yes, 98% confidence

Service 'app' allows for privilege escalation via setuid or setgid binaries. Add 'no-new-privileges:true' in 'security_opt' to prevent this.

app:

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /plugins/wp-graphql-acf/docker-compose.yml line 4
Likely real: Yes, 98% confidence

Service 'app' allows for privilege escalation via setuid or setgid binaries. Add 'no-new-privileges:true' in 'security_opt' to prevent this.

app:

Engine: GuardDog · Supply-chain attack heuristics
Counts towards: Malicious pattern
File: /websites/wpgraphql.com/.yarn/releases/yarn-1.22.19.cjs line 85060
Likely real: Yes, 97% confidence

Detects URLs to URL shorteners, file sharing, and suspicious services [threat-network-outbound-shady-links]

..."hopto.org":true,"myftp.biz":true,"myftp.org":true,"myvnc.com":true,"no-ip.biz":true,"no-ip.info":true,"no-ip.org":true,"noip.me":true,"redirectme.net":true,"servebeer.com":true,"serveblog.net":true,"servecounterstrike.com":true,"serveftp.com":true,...

Engine: GuardDog · Supply-chain attack heuristics
Counts towards: Malicious pattern
File: /websites/wpgraphql.com/.yarn/releases/yarn-1.22.19.cjs line 85060
Likely real: Yes, 97% confidence

Detects URLs to URL shorteners, file sharing, and suspicious services [threat-network-outbound-shady-links]

...,"hopto.org":true,"myftp.biz":true,"myftp.org":true,"myvnc.com":true,"no-ip.biz":true,"no-ip.info":true,"no-ip.org":true,"noip.me":true,"redirectme.net":true,"servebeer.com":true,"serveblog.net":true,"servecounterstrike.com":true,"serveftp.com":true,...

Engine: GuardDog · Supply-chain attack heuristics
Counts towards: Malicious pattern
File: /websites/wpgraphql.com/.yarn/releases/yarn-1.22.19.cjs line 85060
Likely real: Yes, 97% confidence

Detects URLs to URL shorteners, file sharing, and suspicious services [threat-network-outbound-shady-links]

...moattachments.org":true,"net.ru":true,"org.ru":true,"pp.ru":true,"bitballoon.com":true,"netlify.com":true,"4u.com":true,"ngrok.io":true,"nh-serv.co.uk":true,"nfshost.com":true,"nsupdate.info":true,"nerdpol.ovh":true,"blogsyte.com":true,"brasilia.me":...

Engine: GuardDog · Supply-chain attack heuristics
Counts towards: Malicious pattern
File: /websites/wpgraphql.com/.yarn/releases/yarn-1.22.19.cjs line 85060
Likely real: Yes, 97% confidence

Detects URLs to URL shorteners, file sharing, and suspicious services [threat-network-outbound-shady-links]

...moattachments.org":true,"net.ru":true,"org.ru":true,"pp.ru":true,"bitballoon.com":true,"netlify.com":true,"4u.com":true,"ngrok.io":true,"nh-serv.co.uk":true,"nfshost.com":true,"nsupdate.info":true,"nerdpol.ovh":true,"blogsyte.com":true,"brasilia.me"...

Engine: GuardDog · Supply-chain attack heuristics
Counts towards: Malicious pattern
File: /websites/wpgraphql.com/.yarn/releases/yarn-1.22.19.cjs line 48453
Likely real: Yes, 97% confidence

Detects URLs to URL shorteners, file sharing, and suspicious services [threat-network-outbound-shady-links]

'rhino', // once a target for older modules
'cordovaDependencies', // http://bit.ly/2tkUePg
'parcel'];

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /plugins/wp-graphql-ide/plugins/help-panel/.npmrc line 1
Likely real: Yes, 97% confidence

This .npmrc does not set a minimum release age or sets it too low. Newly published packages can be malicious or unstable. Add `min-release-age = 7` to wait 7 days before resolving newly published package versions. Added in: v11.10 Reference: https://github.blog/changelog/2026-02-18-npm-bulk-trusted-publishing-config-and-script-security-now-generally-available/

package-lock = false

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /plugins/wp-graphql-ide/plugins/query-composer-panel/.npmrc line 1
Likely real: Yes, 97% confidence

This .npmrc does not set a minimum release age or sets it too low. Newly published packages can be malicious or unstable. Add `min-release-age = 7` to wait 7 days before resolving newly published package versions. Added in: v11.10 Reference: https://github.blog/changelog/2026-02-18-npm-bulk-trusted-publishing-config-and-script-security-now-generally-available/

package-lock = false

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /plugins/wp-graphql-acf/docker-compose.yml line 4
Likely real: Yes, 97% confidence

Service 'app' is running with a writable root filesystem. This may allow malicious applications to download and run additional payloads, or modify container files. If an application inside a container has to save something temporarily consider using a tmpfs. Add 'read_only: true' to this service to prevent this.

app:

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /plugins/wp-graphql-smart-cache/docker-compose.yml line 14
Likely real: Yes, 97% confidence

Service 'app' is running with a writable root filesystem. This may allow malicious applications to download and run additional payloads, or modify container files. If an application inside a container has to save something temporarily consider using a tmpfs. Add 'read_only: true' to this service to prevent this.

app:

Engine: GuardDog · Supply-chain attack heuristics
Counts towards: Malicious pattern
File: /websites/wpgraphql.com/.yarn/releases/yarn-1.22.19.cjs line 96080
Likely real: Yes, 96% confidence

Detects access to sensitive files (credentials, configs, keys) [threat-filesystem-read]

..._load_commander()).default.option('--use-yarnrc <path>', 'specifies a yarnrc file that Yarn should use (.yarnrc only, not .npmrc)', collect, []);
    (_commander || _load_commander()).default.option('--verbose', 'output verbose messages on internal o...

Engine: GuardDog · Supply-chain attack heuristics
Counts towards: Malicious pattern
File: /websites/wpgraphql.com/.yarn/releases/yarn-1.22.19.cjs line 44708
Likely real: Yes, 96% confidence

Detects access to sensitive files (credentials, configs, keys) [threat-filesystem-read]

// ignore cruft
'yarn.lock', '.lock-wscript', '.wafpickle-{0..9}', '*.swp', '._*', 'npm-debug.log', 'yarn-error.log', '.npmrc', '.yarnrc', '.yarnrc.yml', '.npmignore', '.gitignore', '.DS_Store']);

const NEVER_IGNORE = (0, (_filter || _load_filter...

Engine: GuardDog · Supply-chain attack heuristics
Counts towards: Malicious pattern
File: /scripts/recipes/migrate-recipes-from-wp.js line 337
Likely real: Yes, 96% confidence

Detects access to sensitive files (credentials, configs, keys) [threat-filesystem-read]

loadEnvFile(path.join(repoRoot, 'websites', 'wpgraphql.com', '.env.local'));

	if (!pluginSlug) {

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /scripts/recipes/recipe-relations.js line 124
Likely real: Yes, 76% confidence

RegExp() called with a `name` function argument, this might allow an attacker to cause a Regular Expression Denial-of-Service (ReDoS) within your application as RegExP blocks the main thread. For this reason, it is recommended to use hardcoded regexes instead. If your regex is run on user-controlled input, consider performing input validation or use a regex checking/sanitization library such as https://www.npmjs.com/package/recheck to verify that the regex does not appear vulnerable to ReDoS.

const re = new RegExp(`(?:^|[^a-z0-9_])${esc}(?:[^a-z0-9_]|$)`, 'i');

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/workflows/lint.yml line 162
Likely real: Yes, 52% confidence

GitHub Actions step uses a mutable tag or branch reference. Tags and branch names can be silently repointed by the action owner, enabling supply-chain attacks — as seen in the trivy-action and kics-github-action compromises. Pin the reference to a full 40-character commit SHA instead, e.g. `uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608`.

uses: actions/checkout@v7.0.1

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/workflows/lint.yml line 167
Likely real: Yes, 52% confidence

GitHub Actions step uses a mutable tag or branch reference. Tags and branch names can be silently repointed by the action owner, enabling supply-chain attacks — as seen in the trivy-action and kics-github-action compromises. Pin the reference to a full 40-character commit SHA instead, e.g. `uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608`.

uses: actions/setup-node@v7

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/workflows/schema-linter-reusable.yml line 87
Likely real: Yes, 52% confidence

GitHub Actions step uses a mutable tag or branch reference. Tags and branch names can be silently repointed by the action owner, enabling supply-chain attacks — as seen in the trivy-action and kics-github-action compromises. Pin the reference to a full 40-character commit SHA instead, e.g. `uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608`.

uses: nick-fields/retry@v4

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/workflows/smoke-test-reusable.yml line 179
Likely real: Yes, 52% confidence

GitHub Actions step uses a mutable tag or branch reference. Tags and branch names can be silently repointed by the action owner, enabling supply-chain attacks — as seen in the trivy-action and kics-github-action compromises. Pin the reference to a full 40-character commit SHA instead, e.g. `uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608`.

uses: nick-fields/retry@v4

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/workflows/upload-schema-artifact.yml line 63
Likely real: Yes, 52% confidence

GitHub Actions step uses a mutable tag or branch reference. Tags and branch names can be silently repointed by the action owner, enabling supply-chain attacks — as seen in the trivy-action and kics-github-action compromises. Pin the reference to a full 40-character commit SHA instead, e.g. `uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608`.

uses: nick-fields/retry@v4

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /websites/wpgraphql.com/.github/actions/cache-restore/action.yml line 14
Likely real: Yes, 52% confidence

GitHub Actions step uses a mutable tag or branch reference. Tags and branch names can be silently repointed by the action owner, enabling supply-chain attacks — as seen in the trivy-action and kics-github-action compromises. Pin the reference to a full 40-character commit SHA instead, e.g. `uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608`.

uses: actions/setup-node@v3

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /websites/wpgraphql.com/.github/actions/cache-restore/action.yml line 21
Likely real: Yes, 52% confidence

GitHub Actions step uses a mutable tag or branch reference. Tags and branch names can be silently repointed by the action owner, enabling supply-chain attacks — as seen in the trivy-action and kics-github-action compromises. Pin the reference to a full 40-character commit SHA instead, e.g. `uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608`.

uses: actions/cache@v3

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /websites/wpgraphql.com/.github/workflows/validate_pr.yml line 12
Likely real: Yes, 52% confidence

GitHub Actions step uses a mutable tag or branch reference. Tags and branch names can be silently repointed by the action owner, enabling supply-chain attacks — as seen in the trivy-action and kics-github-action compromises. Pin the reference to a full 40-character commit SHA instead, e.g. `uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608`.

uses: actions/checkout@v3

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /websites/wpgraphql.com/.github/workflows/validate_pr.yml line 27
Likely real: Yes, 52% confidence

GitHub Actions step uses a mutable tag or branch reference. Tags and branch names can be silently repointed by the action owner, enabling supply-chain attacks — as seen in the trivy-action and kics-github-action compromises. Pin the reference to a full 40-character commit SHA instead, e.g. `uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608`.

uses: actions/checkout@v3

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /websites/wpgraphql.com/.github/workflows/validate_pr.yml line 41
Likely real: Yes, 52% confidence

GitHub Actions step uses a mutable tag or branch reference. Tags and branch names can be silently repointed by the action owner, enabling supply-chain attacks — as seen in the trivy-action and kics-github-action compromises. Pin the reference to a full 40-character commit SHA instead, e.g. `uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608`.

uses: actions/checkout@v3

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /plugins/wp-graphql-ide/src/components/document-settings/DocumentSettingsDrawer.jsx line 88
Likely real: Uncertain, 47% confidence

Detection of dangerouslySetInnerHTML from non-constant definition. This can inadvertently expose users to cross-site scripting (XSS) attacks if this comes from user-provided input. If you have to use dangerouslySetInnerHTML, consider using a sanitization library such as DOMPurify to sanitize your HTML.

dangerouslySetInnerHTML={{ __html: field.desc }}

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /plugins/wp-graphql-ide/src/components/document-settings/DocumentSettingsDrawer.jsx line 112
Likely real: Uncertain, 47% confidence

Detection of dangerouslySetInnerHTML from non-constant definition. This can inadvertently expose users to cross-site scripting (XSS) attacks if this comes from user-provided input. If you have to use dangerouslySetInnerHTML, consider using a sanitization library such as DOMPurify to sanitize your HTML.

dangerouslySetInnerHTML={{ __html: field.desc }}

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /plugins/wp-graphql-ide/src/components/document-settings/DocumentSettingsDrawer.jsx line 136
Likely real: Uncertain, 47% confidence

Detection of dangerouslySetInnerHTML from non-constant definition. This can inadvertently expose users to cross-site scripting (XSS) attacks if this comes from user-provided input. If you have to use dangerouslySetInnerHTML, consider using a sanitization library such as DOMPurify to sanitize your HTML.

dangerouslySetInnerHTML={{ __html: field.desc }}

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /plugins/wp-graphql-ide/src/components/document-settings/fields/RadioWithDefaultField.jsx line 78
Likely real: Uncertain, 47% confidence

Detection of dangerouslySetInnerHTML from non-constant definition. This can inadvertently expose users to cross-site scripting (XSS) attacks if this comes from user-provided input. If you have to use dangerouslySetInnerHTML, consider using a sanitization library such as DOMPurify to sanitize your HTML.

dangerouslySetInnerHTML={{ __html: field.desc }}

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /plugins/wp-graphql-ide/src/components/document-settings/fields/TagListField.jsx line 117
Likely real: Uncertain, 47% confidence

Detection of dangerouslySetInnerHTML from non-constant definition. This can inadvertently expose users to cross-site scripting (XSS) attacks if this comes from user-provided input. If you have to use dangerouslySetInnerHTML, consider using a sanitization library such as DOMPurify to sanitize your HTML.

dangerouslySetInnerHTML={{ __html: field.desc }}

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /plugins/wp-graphql-ide/src/components/settings/SettingsField.jsx line 26
Likely real: Uncertain, 47% confidence

Detection of dangerouslySetInnerHTML from non-constant definition. This can inadvertently expose users to cross-site scripting (XSS) attacks if this comes from user-provided input. If you have to use dangerouslySetInnerHTML, consider using a sanitization library such as DOMPurify to sanitize your HTML.

dangerouslySetInnerHTML={{ __html: field.desc }}

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /plugins/wp-graphql-ide/src/components/settings/SettingsField.jsx line 278
Likely real: Uncertain, 47% confidence

Detection of dangerouslySetInnerHTML from non-constant definition. This can inadvertently expose users to cross-site scripting (XSS) attacks if this comes from user-provided input. If you have to use dangerouslySetInnerHTML, consider using a sanitization library such as DOMPurify to sanitize your HTML.

dangerouslySetInnerHTML={{ __html: field.html }}

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /websites/wpgraphql.com/src/components/Preview/PreviewCard.js line 42
Likely real: Uncertain, 47% confidence

Detection of dangerouslySetInnerHTML from non-constant definition. This can inadvertently expose users to cross-site scripting (XSS) attacks if this comes from user-provided input. If you have to use dangerouslySetInnerHTML, consider using a sanitization library such as DOMPurify to sanitize your HTML.

dangerouslySetInnerHTML={{ __html: excerpt }}

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /websites/wpgraphql.com/src/wp-templates/archive.js line 146
Likely real: Uncertain, 47% confidence

Detection of dangerouslySetInnerHTML from non-constant definition. This can inadvertently expose users to cross-site scripting (XSS) attacks if this comes from user-provided input. If you have to use dangerouslySetInnerHTML, consider using a sanitization library such as DOMPurify to sanitize your HTML.

<div dangerouslySetInnerHTML={{ __html: archive.description }} />

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /websites/wpgraphql.com/src/wp-templates/archive.js line 205
Likely real: Uncertain, 47% confidence

Detection of dangerouslySetInnerHTML from non-constant definition. This can inadvertently expose users to cross-site scripting (XSS) attacks if this comes from user-provided input. If you have to use dangerouslySetInnerHTML, consider using a sanitization library such as DOMPurify to sanitize your HTML.

dangerouslySetInnerHTML={{ __html: archive.description }}

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /websites/wpgraphql.com/src/wp-templates/author.js line 40
Likely real: Uncertain, 47% confidence

Detection of dangerouslySetInnerHTML from non-constant definition. This can inadvertently expose users to cross-site scripting (XSS) attacks if this comes from user-provided input. If you have to use dangerouslySetInnerHTML, consider using a sanitization library such as DOMPurify to sanitize your HTML.

__html: data?.user?.description ?? "",

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /websites/wpgraphql.com/src/wp-templates/single-code-snippet.js line 149
Likely real: Uncertain, 47% confidence

Detection of dangerouslySetInnerHTML from non-constant definition. This can inadvertently expose users to cross-site scripting (XSS) attacks if this comes from user-provided input. If you have to use dangerouslySetInnerHTML, consider using a sanitization library such as DOMPurify to sanitize your HTML.

<div id="content" dangerouslySetInnerHTML={{ __html: content }} />

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /websites/wpgraphql.com/src/wp-templates/single-developer-reference.js line 28
Likely real: Uncertain, 47% confidence

Detection of dangerouslySetInnerHTML from non-constant definition. This can inadvertently expose users to cross-site scripting (XSS) attacks if this comes from user-provided input. If you have to use dangerouslySetInnerHTML, consider using a sanitization library such as DOMPurify to sanitize your HTML.

dangerouslySetInnerHTML={{ __html: post.content }}

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /websites/wpgraphql.com/src/wp-templates/singular.js line 79
Likely real: Uncertain, 47% confidence

Detection of dangerouslySetInnerHTML from non-constant definition. This can inadvertently expose users to cross-site scripting (XSS) attacks if this comes from user-provided input. If you have to use dangerouslySetInnerHTML, consider using a sanitization library such as DOMPurify to sanitize your HTML.

dangerouslySetInnerHTML={{ __html: post.content }}

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /plugins/wp-graphql-ide/src/components/ResponseTableView.jsx line 15
Likely real: Uncertain, 44% confidence

Possibility of prototype polluting function detected. By adding or modifying attributes of an object prototype, it is possible to create attributes that exist on every object, or replace critical attributes with malicious ones. This can be problematic if the software depends on existence or non-existence of certain attributes, or uses pre-defined attributes of object prototype (such as hasOwnProperty, toString or valueOf). Possible mitigations might be: freezing the object prototype, using an object without prototypes (via Object.create(null) ), blocking modifications of attributes that resolve to object prototype, using Map instead of object.

val = val[seg];

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /scripts/hooks/generate-hook-docs.js line 254
Likely real: Uncertain, 37% confidence