Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

Python: server_url_validator allows Azure WireServer (168.63.129.16) and IPv6-embedded IPv4 forms (NAT64/6to4/Teredo)

未关闭
  • 哪里不对？
#14,240 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 2 天内回复

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
55/100
Issue 类型
缺陷
描述清晰度
基本清楚
活跃度
冷清
技术栈
python
领域
api, security

调研方向

从 semantic_kernel.connectors.openapi_plugin.server_url_validator 中的 validate_server_url 开始，然后检查 try_categorize_non_public_address 以及 IPv4/IPv6 分类辅助函数。使用 issue 中的复现地址和预期行为进行检查；当 Azure WireServer 被阻止，并且 NAT64、6to4 和 Teredo 形式在分类前被解码时，即表示完成。

由索引模型根据 Issue 内容生成。

描述

Describe the bug

server_url_validator is the default SSRF guard for OpenAPI plugin calls (allow_private_network_access defaults to False), and it classifies IPv4 by explicit octet ranges and IPv6 by a short list of properties. Two categories fall outside both:

  • 168.63.129.16 — Azure's WireServer / platform channel, reachable from every Azure VM. It's a publicly routable address, so none of the _try_classify_ipv4 branches match it.
  • IPv6 addresses that carry an IPv4 target inside them. _try_classify_ipv6 unwraps ::ffff: via ipv4_mapped, but NAT64, 6to4 and Teredo encodings aren't decoded.

The URL an OpenAPI plugin ends up calling is influenced by the model (server variables, path parameters), which is what makes this the SSRF surface the module exists for.

To Reproduce
import asyncio
from semantic_kernel.connectors.openapi_plugin.server_url_validator import validate_server_url

asyncio.run(validate_server_url("https://168.63.129.16/machine/"))            # returns
asyncio.run(validate_server_url("https://[64:ff9b::169.254.169.254]/latest/meta-data/"))  # returns

Full sweep on main @ 7d885dd:

address result category reported
169.254.169.254 (AWS/GCP/Azure/OCI/DO IMDS) blocked link-local
169.254.170.2 (AWS ECS task creds) blocked link-local
169.254.170.23 (AWS EKS Pod Identity) blocked link-local
169.254.42.42 (Scaleway) blocked link-local
100.100.100.200 (Alibaba) blocked carrier-grade NAT
192.0.0.192 (Oracle Cloud Classic) blocked reserved
168.63.129.16 (Azure WireServer) allowed —
IPv6 form result
::ffff:169.254.169.254 (IPv4-mapped) blocked
::1, fd00:ec2::254 blocked
64:ff9b::169.254.169.254 (NAT64 well-known, RFC 6052) allowed
2002:a9fe:a9fe:: (6to4, RFC 3056) allowed
2001:0:4136:e378:8000:63bf:3fff:fdd2 (Teredo, RFC 4380) allowed
Expected behavior

168.63.129.16 blocked regardless of the private-range classification, and IPv6 forms carrying an embedded IPv4 decoded to that IPv4 before classification.

The Azure one can't be caught by range logic — it needs an explicit metadata denylist, checked before allow_private_network_access returns early, since "let me reach my own network" and "let me reach the host agent's credential endpoint" aren't the same request.

NAT64 needs the 64:ff9b::/96 and 64:ff9b:1::/48 prefixes decoded per RFC 6052 §2.2; 6to4 takes the IPv4 from bits 16–47; Teredo's is the low 32 bits XOR'd with all-ones.

Platform
  • OS: Linux
  • Python: 3.10.12
  • Semantic Kernel: main @ 7d885dd (python)
Additional context

Reachability varies by deployment — NAT64 needs a gateway on the path, and 6to4/Teredo relays are largely retired, so those three are defence-in-depth rather than universally exploitable. 168.63.129.16 is different: it is directly reachable on any Azure VM with no special network setup, which is where this repo's users are most likely to be running.

The IPv4-mapped unwrapping in try_categorize_non_public_address is already the right shape for the IPv6 side; the other encodings would slot in next to it.

主要语言
C#
星标
28.6k
派生
4.8k
平均合并
13 小时 24 分钟
30 天内合并 PR
11

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

microsoft/semantic-kernel 的其他 Issue

查看 microsoft/semantic-kernel 的全部 Issue

相似的 Issue

更多 C# Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。