Problemas conhecidos com a Apigee

When the cachehit flow variable is used after the LookupCache policy, due to the way debug points are dispatched for asynchronous behavior, the LookupPolicy populates the DebugInfo object before the call back has executed, resulting in an error.

Workaround: Repeat the process (make second call) again right after the first call.

Setting PurgeChildEntries in the InvalidateCache policy should purge the KeyFragment element values only but clears the entire cache.

Workaround: Use the KeyValueMapOperations policy to iterate cache versioning and bypass the need for cache invalidation.

This can happen, for example, when concurrent runs of a CI/CD deployment pipeline occur using different revisions. To avoid this problem, avoid deploying API proxies or SharedFlows before the current deployment is complete.

Workaround: Avoid concurrent API proxy or SharedFlow deployments.

Edge API Analytics can sometimes contain duplicate data for API calls. In that case the counts shown for API calls in Edge API Analytics are higher than the comparable values shown in third-party analytics tools.

Workaround: Export the analytics data and use the gateway_flow_id field to de-duplicate the data.

When you connect an organization to an identity zone, you can no longer access the Edge SSO Zone Administration page from the left navigation bar by selecting Admin > SSO.

Workaround: Navigate to the page directly using the following URL: https://apigee.com/sso

The options TLS_DISABLED_ALGO and TLS_ENABLED_CIPHERS do not function correctly.

Workaround: Follow the steps below to enable specific ciphers for the Edge UI:

1. Open the /opt/apigee/etc/edge-ui.d/SSL.sh config file.
2. Add the property -Djdk.tls.server.cipherSuites with a comma-separated list of cipher suites in IANA notation inside the UI_OPTIONS. For example:

   UI_OPTIONS=" -Dhttp.port=disabled -Dhttps.port=9433 -Dhttps.keyStoreType=JKS -Dhttps.keyStore=/opt/apigee/customer/conf/keystore.jks -Dplay.http.sslengineprovider=services.CustomSSLEngineProvider -Dhttps.keyStorePasswordEncrypted=mypass -Djdk.tls.server.cipherSuites=TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_GCM_SHA384"

3. Save your changes to the config file.
4. Restart the Edge UI:

   /opt/apigee/apigee-service/bin/apigee-service edge-ui restart

• Apigee Edge supports OpenAPI Specification 3.0 when you create specifications using the spec editor and publish APIs using SmartDocs on your portal, though a subset of features are not yet supported.

  For example, the following features from the OpenAPI Specification 3.0 are not yet supported:

  • allOf properties for combining and extending schemas
  • Remote references

  If an unsupported feature is referenced in your OpenAPI Specification, in some cases the tools will ignore the feature but still render the API reference documentation. In other cases, an unsupported feature will cause errors that prevent the successful rendering of the API reference documentation. In either case, you will need to modify your OpenAPI Specification to avoid use of the unsupported feature until it is supported in a future release.

  Note: Because the spec editor is less restrictive than SmartDocs when rendering API reference documentation, you may experience different results between the tools.

• When using Try this API in the portal, the Accept header is set to application/json regardless of the value set for consumes in the OpenAPI Specification.
• 138438484: Multiple servers are not supported.

• Simultaneous portal updates (such as page, theme, CSS, or script edits) by multiple users is not supported at this time.
• If you delete an API reference documentation page from the portal, there is no way to recreate it; you'll need to delete and re-add the API product, and regenerate the API reference documentation.
• When configuring the content security policy, it may take up to 15 minutes for changes to fully apply.
• When customizing your portal theme, it may take up to 5 minutes for changes to fully apply.

• Search will be integrated into the integrated portal in a future release.

Uma vulnerabilidade (CVE-2026-42945) foi divulgada e afeta o ngx_http_rewrite_module no NGINX. As ferramentas de verificação de segurança podem sinalizar os binários do NGINX incluídos no Apigee Edge para nuvem privada porque esse módulo é compilado de forma estática no NGINX.

Impacto no Apigee Edge para nuvem privada:

O Apigee Edge para nuvem privada não é afetado por essa vulnerabilidade na configuração padrão enviada. A capacidade de exploração da CVE-2026-42945 depende de padrões de configuração específicos do NGINX, principalmente o uso da diretiva rewrite em uma sequência específica. Esses padrões não estão presentes em nenhuma configuração padrão do NGINX do Apigee Edge para nuvem privada.

Ação necessária:

• Para configurações padrão do Apigee Edge para nuvem privada:não são necessários patches, upgrades ou mudanças operacionais. Os resultados do scanner relacionados ao CVE-2026-42945 podem ser tratados como falsos positivos para instalações padrão. Use o texto a seguir para documentar essa exceção no seu sistema de gestão de vulnerabilidades:

  CVE-2026-42945 — Accepted exception (false positive for Apigee Edge for Private Cloud). Apigee Edge for Private Cloud does not use the rewrite directive in any shipped NGINX configuration. The vulnerable code path in ngx_http_rewrite_module is configuration-gated and is not reachable in the default Apigee Edge for Private Cloud deployment.

• Para configurações personalizadas do NGINX:se você modificou manualmente os arquivos de configuração do NGINX na instalação do Apigee Edge para nuvem privada (por exemplo, em /opt/nginx), faça a seguinte autoverificação para garantir que suas personalizações não introduziram inadvertidamente o padrão vulnerável:
  1. Verifique a diretiva de reescrita:em cada nó do NGINX, execute o comando:

     sudo grep -rnI '^\s*rewrite\b' /opt/nginx

  2. Analisar resultados:
     • Se o comando não retornar nenhuma saída, seu sistema não será afetado.
     • Se forem encontradas correspondências, analise cada instância. A vulnerabilidade estará presente somente se todas as condições a seguir forem atendidas para um determinado bloco:
       • A diretiva rewrite é usada.
       • Ele é imediatamente seguido por outra diretiva rewrite, if ou set no mesmo bloco de configuração.
       • Um grupo de captura PCRE sem nome (por exemplo, $1, $2 etc.) é usado nas diretivas.
       • A string de substituição na diretiva contém um ponto de interrogação (?).
  3. Mitigação (se vulnerável): se todas as condições acima forem verdadeiras para qualquer parte da sua configuração personalizada, faça a mitigação:
     • Remover o ponto de interrogação (?) da string de substituição.
     • Usar grupos de captura nomeados em vez de não nomeados.
     • Reavaliar a necessidade das diretivas encadeadas.

No Edge para nuvem privada 4.53.00 e versões mais recentes, a interface mostra um pop-up de aviso de fim da vida útil (EOL). Esse aviso aparece
repetidamente e não pode ser evitado ou reduzido em frequência.

No momento, não há um método disponível para os usuários desativarem ou reduzirem a frequência desse aviso de fim da vida útil.

As chamadas Java do cliente que tentam carregar o provedor de criptografia Bouncy Castle usando o nome "BC" podem falhar porque o provedor padrão foi alterado para Bouncy Castle FIPS para oferecer suporte ao FIPS. O novo nome do provedor a ser usado é "BCFIPS".

As chamadas Java do cliente que tentam carregar o provedor de criptografia Bouncy Castle usando o nome "BC" podem falhar porque o provedor padrão foi alterado para Bouncy Castle FIPS para oferecer suporte ao FIPS. O novo nome do provedor a ser usado é "BCFIPS".

Esse problema afeta apenas quem usa o MINT ou tem o MINT ativado nas instalações do Edge para nuvem privada.

Componente afetado:edge-message-processor

Problema:se você tiver a monetização ativada e estiver instalando a versão 4.52.01 como uma nova instalação ou fazendo upgrade de versões anteriores da nuvem privada, vai encontrar um problema com os processadores de mensagens. Haverá um aumento gradual na contagem de linhas de execução abertas, o que vai levar ao esgotamento de recursos. A seguinte exceção é encontrada em edge-message-processor system.log:

Error injecting constructor, java.lang.OutOfMemoryError: unable to create new native thread

Uma vulnerabilidade de negação de serviço (DoS) foi descoberta recentemente em várias implementações do protocolo HTTP/2 (CVE-2023-44487), incluindo o Apigee Edge para nuvem privada. A vulnerabilidade pode levar a um DoS da funcionalidade de gerenciamento da API Apigee. Para mais detalhes, consulte o boletim de segurança da Apigee GCP-2023-032.

Os componentes do roteador e do servidor de gerenciamento do Edge para nuvem privada estão expostos à Internet e podem estar vulneráveis. Embora o HTTP/2 esteja ativado na porta de gerenciamento de outros componentes específicos do Edge relativos ao Edge para nuvem privada, nenhum deles está exposto à Internet. Em componentes que não são do Edge, como Cassandra, Zookeeper e outros, o HTTP/2 não está ativado. Recomendamos que você siga as etapas abaixo para resolver a vulnerabilidade do Edge para nuvem privada:

• Etapas para versões do Edge para nuvem privada 4.51.00.11 ou mais recentes
• Etapas para versões do Edge para nuvem privada anteriores à 4.51.00.11

Siga estas etapas se estiver usando o Edge Private Cloud nas versões 4.51.00.11 ou mais recentes:

1. Atualizar o servidor de gerenciamento:

   1. Em cada nó do servidor de gerenciamento, abra /opt/apigee/customer/application/management-server.properties
   2. Adicione esta linha ao arquivo de propriedades:

      conf_webserver_http2.enabled=false

   3. Reinicie o componente do servidor de gerenciamento:

      apigee-service edge-management-server restart

2. Atualize o processador de mensagens:

   1. Em cada nó do processador de mensagens, abra /opt/apigee/customer/application/message-processor.properties
   2. Adicione esta linha ao arquivo de propriedades:

      conf_webserver_http2.enabled=false

   3. Reinicie o componente do processador de mensagens:

      apigee-service edge-message-processor restart

3. Atualize o roteador:

   1. Em cada nó de roteador, abra /opt/apigee/customer/application/router.properties
   2. Adicione esta linha ao arquivo de propriedades:

      conf_webserver_http2.enabled=false

   3. Reinicie o componente do processador de mensagens:

      apigee-service edge-router restart

4. Atualizar QPID:

   1. Em cada nó do QPID, abra /opt/apigee/customer/application/qpid-server.properties
   2. Adicione esta linha ao arquivo de propriedades:

      conf_webserver_http2.enabled=false

   3. Reinicie o componente do processador de mensagens:

      apigee-service edge-qpid-server restart

5. Atualizar o Postgres:

   1. Em cada nó do Postgres, abra /opt/apigee/customer/application/postgres-server.properties
   2. Adicione esta linha ao arquivo de propriedades:

      conf_webserver_http2.enabled=false

   3. Reinicie o componente do processador de mensagens:

      apigee-service edge-postgres-server restart

Siga estas etapas se estiver usando versões do Edge para nuvem privada anteriores à 4.51.00.11:

1. Atualizar o servidor de gerenciamento:

   1. Em cada nó do servidor de gerenciamento, abra /opt/apigee/customer/application/management-server.properties
   2. Adicione as duas linhas a seguir ao arquivo de propriedades:

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. Reinicie o componente do servidor de gerenciamento:

      apigee-service edge-management-server restart

2. Atualize o processador de mensagens:

   1. Em cada nó do processador de mensagens, abra /opt/apigee/customer/application/message-processor.properties
   2. Adicione as duas linhas a seguir ao arquivo de propriedades:

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. Reinicie o componente do processador de mensagens:

      apigee-service edge-message-processor restart

3. Atualize o roteador:

   1. Em cada nó de roteador, abra /opt/apigee/customer/application/router.properties
   2. Adicione as duas linhas a seguir ao arquivo de propriedades:

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. Reinicie o componente do processador de mensagens:

      apigee-service edge-router restart

4. Atualizar QPID:

   1. Em cada nó do QPID, abra /opt/apigee/customer/application/qpid-server.properties
   2. Adicione as duas linhas a seguir ao arquivo de propriedades:

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. Reinicie o componente do processador de mensagens:

      apigee-service edge-qpid-server restart

5. Atualizar o Postgres:

   1. Em cada nó do Postgres, abra /opt/apigee/customer/application/postgres-server.properties
   2. Adicione as duas linhas a seguir ao arquivo de propriedades:

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. Reinicie o componente do processador de mensagens:

      apigee-service edge-postgres-server restart

O Apigee-postgresql está com problemas ao fazer upgrade do Edge para nuvem privada versão 4.50 ou 4.51 para a versão 4.52. Os problemas ocorrem principalmente quando o número de tabelas é maior que 500.

Para verificar o número total de tabelas no Postgres, execute a consulta SQL abaixo:

select count(*) from information_schema.tables

Solução alternativa:ao atualizar o Apigee Edge 4.50.00 ou 4.51.00 para 4.52.00, execute a etapa preliminar antes de fazer upgrade do Apigee-postgresql.

149245401: as configurações do pool de conexões LDAP para JNDI configuradas pelo recurso LDAP não são refletidas, e os padrões do JNDI causam conexões de uso único a cada vez. Como resultado, as conexões são abertas e fechadas a cada vez para uso único, criando um grande número de conexões por hora com o servidor LDAP.

Alternativa:

Para mudar as propriedades do pool de conexões LDAP, siga estas etapas e defina uma mudança global em todas as políticas do LDAP.

1. Crie um arquivo de propriedades de configuração se ele ainda não existir:

   /opt/apigee/customer/application/message-processor.properties

2. Adicione o seguinte ao arquivo (substitua os valores das propriedades da Java Naming and Directory Interface [JNDI] com base no requisito de configuração do recurso LDAP).

   bin_setenv_ext_jvm_opts="-Dcom.sun.jndi.ldap.connect.pool.maxsize=20
   -Dcom.sun.jndi.ldap.connect.pool.prefsize=2
   -Dcom.sun.jndi.ldap.connect.pool.initsize=2
   -Dcom.sun.jndi.ldap.connect.pool.timeout=120000
   -Dcom.sun.jndi.ldap.connect.pool.protocol=ssl"

3. Verifique se o arquivo /opt/apigee/customer/application/message-processor.properties é de propriedade de apigee:apigee.
4. Reinicie cada processador de mensagens.

Para verificar se as propriedades JNDI do pool de conexões estão funcionando, faça um tcpdump para observar o comportamento do pool de conexões LDAP ao longo do tempo.

139051927: altas latências de processamento de proxy encontradas no processador de mensagens estão afetando todos os proxies de API. Os sintomas incluem atrasos de 200 a 300 ms nos tempos de processamento em relação aos tempos normais de resposta da API e podem ocorrer aleatoriamente, mesmo com baixa TPS. Isso pode acontecer quando há mais de 50 servidores de destino em que um processador de mensagens faz conexões.

Causa raiz:os processadores de mensagens mantêm um cache que mapeia o URL do servidor de destino para o objeto HTTPClient para conexões de saída com servidores de destino. Por padrão, essa configuração é definida como 50, o que pode ser muito baixo para a maioria das implantações. Quando uma implantação tem várias combinações de organização/ambiente em uma configuração e um grande número de servidores de destino que excedem 50 no total, os URLs do servidor de destino são removidos do cache, causando latências.

Validação:Para determinar se a remoção do URL do servidor de destino está causando o problema de latência, pesquise nos system.logs do processador de mensagens a palavra-chave "onEvict" ou "Eviction". A presença deles nos registros indica que os URLs do servidor de destino estão sendo removidos do cache HTTPClient porque o tamanho do cache é muito pequeno.

Solução alternativa:Para as versões 19.01 e 19.06 do Edge para nuvem privada, é possível editar e configurar o cache HTTPClient, /opt/apigee/customer/application/message-processor.properties:

conf/http.properties+HTTPClient.dynamic.cache.elements.size=500

Em seguida, reinicie o processador de mensagens. Faça as mesmas mudanças em todos os processadores de mensagens.

O valor 500 é um exemplo. O valor ideal para sua configuração precisa ser maior que o número de servidores de destino a que o processador de mensagens se conectaria. Não há efeitos colaterais de definir essa propriedade como mais alta, e o único efeito seria a melhoria dos tempos de processamento de solicitações de proxy do processador de mensagens.

Observação:o Edge para nuvem privada versão 50.00 tem a configuração padrão de 500.

157933959: inserções e atualizações simultâneas no mesmo mapa de chave-valor (KVM) no escopo da organização ou do ambiente causam dados inconsistentes e perda de atualizações.

Observação:essa limitação se aplica apenas ao Edge para nuvem privada. O Edge para nuvem pública e híbrida não têm essa limitação.

Para uma solução alternativa no Edge para nuvem privada, crie o KVM no escopo apiproxy.