照片分享平台Flickr邮件服务遭遇未授权漏洞攻击正在导致大量数据泄露
Flickr于2026年2月5日获悉事件后数小时内切断了攻击者对受影响系统的访问。
分享平台Flickr表示，其第三方电子邮件服务提供商的安全漏洞可能导致部分用户数据被未经授权访问。
公司披露，受影响的信息包括用户名、电子邮件地址、IP数据和活动日志，密码和支付信息未受影响。
第三方电子邮件服务提供商的安全漏洞可能暴露了Flickr会员的个人信息。
2026年2月5日，这家知名的照片分享平台被警告其外部供应商管理的系统存在漏洞。
这一漏洞可能允许未经授权的个人查看特定会员数据。
目前由SmugMug运营的Flickr迅速采取行动，在发现后数小时内就切断了对被入侵系统的访问权限。
据 Hackread.com 报道，一名使用化名“w1kkid”的黑客于2026年2月2日声称从Substack中提取了超过662,000条用户记录，该公司CEO几天后才证实了这一泄露。
数据暴露详情
虽然任何安全漏洞都令人担忧，但据报道，Flickr的密码和财务信息完全安全。
该漏洞未允许访问加密登录凭证或支付卡号。
可能存在风险的数据包括：
真实姓名及注册电子邮件地址
平台用户活动日志
IP地址与一般地理位置
Flickr用户名和账户类型（比如Pro或Free）
Flickr是摄影界的重要平台，拥有超过280亿张图片，服务于其3500万月用户。不过值得注意的是，公司尚未具体说明受该供应商相关问题影响的账户数量。
公司的回应
在官方安全通知中，Flickr确认他们已通知相关数据保护部门。
为了防止未来出现问题，他们目前正在“加强系统架构”，并加强对所有外部合作伙伴的监督。
“我们对这次事件以及可能引发的担忧深表歉意。我们非常重视您数据的隐私和安全，并正立即采取措施，通过彻底调查、强化系统架构以及进一步加强对第三方服务提供商的监控，防止类似问题发生，“
Flickr总结道。
公司披露，受影响的信息包括用户名、电子邮件地址、IP数据和活动日志，密码和支付信息未受影响。
第三方电子邮件服务提供商的安全漏洞可能暴露了Flickr会员的个人信息。
2026年2月5日，这家知名的照片分享平台被警告其外部供应商管理的系统存在漏洞。
这一漏洞可能允许未经授权的个人查看特定会员数据。
目前由SmugMug运营的Flickr迅速采取行动，在发现后数小时内就切断了对被入侵系统的访问权限。
据 Hackread.com 报道，一名使用化名“w1kkid”的黑客于2026年2月2日声称从Substack中提取了超过662,000条用户记录，该公司CEO几天后才证实了这一泄露。
数据暴露详情
虽然任何安全漏洞都令人担忧，但据报道，Flickr的密码和财务信息完全安全。
该漏洞未允许访问加密登录凭证或支付卡号。
可能存在风险的数据包括：
真实姓名及注册电子邮件地址
平台用户活动日志
IP地址与一般地理位置
Flickr用户名和账户类型（比如Pro或Free）
Flickr是摄影界的重要平台，拥有超过280亿张图片，服务于其3500万月用户。不过值得注意的是，公司尚未具体说明受该供应商相关问题影响的账户数量。
公司的回应
在官方安全通知中，Flickr确认他们已通知相关数据保护部门。
为了防止未来出现问题，他们目前正在“加强系统架构”，并加强对所有外部合作伙伴的监督。
“我们对这次事件以及可能引发的担忧深表歉意。我们非常重视您数据的隐私和安全，并正立即采取措施，通过彻底调查、强化系统架构以及进一步加强对第三方服务提供商的监控，防止类似问题发生，“
Flickr总结道。
关于作者
评论1次
结论： 攻击面核心为第三方邮件服务供应商API或数据库的未授权访问漏洞，暴露用户非敏感但高价值的关联数据（如IP/活动日志）。需优先排查第三方接口权限外溢与API边界控制失效问题，其次验证日志异常流量与供应商安全基线合规性。 --- ### 分析路径（T00ls方法论） **L1 攻击面识别** - **源（Source）**：第三方邮件服务商的用户数据存储（如数据库、API端点） - **漏洞载体**： 1. 第三方xi统API未实施细粒度权限控制（如未授权API端点暴露） 2. 供应商基础设施配置错误（如S3存储桶权限泄漏） 3. 供应商身份验证机制薄弱（如API密钥硬编码或长期未轮换） - **Sink**：敏感数据未被加密或脱敏直接暴露（如明文IP地址、活动日志） **L2 假设与验证** 假设漏洞源于第三方API接口的不当配置： - 验证假设1：模拟外部攻击者视角，测试是否存在未授权API端点（如`/api/v1/users?limit=1000000`） - 验证假设2：检查供应商xi统日志是否存在异常高频率数据拉取请求（如每秒>100次请求） - 验证假设3：验证Flickr与供应商之间是否实施双向认证（如OAuth2.0+IP白名单） **L3 边界/异常场景** - **边界测试**：尝试通过供应商API获取非自身用户数据（如伪造用户ID或越权访问其他用户日志） - **异常流量**：分析Flickr侧的访问日志，定位2月2日前后是否存在异常的大规模数据导出行为（如单次请求返回数十万用户数据） - **横向移动检测**：检查泄露数据是否包含可关联到Flickr内部xi统的元数据（如内部服务IP或API文档） **L4 防御反推与修复** 供应商漏洞暴露Flickr在第三方管控上的薄弱点： 1. **权限最小化**：确保供应商仅能访问必要数据（如邮件相关字段而非用户活动日志） 2. **监控缺失**：未及时发现供应商API的异常调用行为（如未配置SIEM规则监控第三方接口异常流量） 3. **审计失效**：供应商安全审计流于形式，未复现真实攻击场景 --- ### 验证步骤 1. **接口枚举与权限测试** ```bash # 模拟API探测（需替换为真实端点） curl -v "https://vendor-api.example.com/flickr/users?offset=0&limit=100000" # 检查响应是否返回用户IP/活动日志等字段 ``` 2. **日志分析** ```bash # 提取供应商API访问日志（假设日志字段包含status_code和request_params） grep "200 OK" /var/log/flickr/vendor_api.log | awk -F' ' '{print $7}' | sort | uniq -c # 识别高频请求IP或异常limit参数（如limit=100000） ``` 3. **配置核查** - 检查供应商API密钥是否绑定Flickr服务器IP白名单 - 确认供应商xi统启用MFA和API调用速率限制 --- ### 修复建议 1. **供应商管控加固** - 强制要求供应商API采用OAuth2.0+JWT，并实施细粒度作用域划分（如邮件服务仅允许操作用户自身邮箱数据） - 在供应商xi统中设置Flickr专属虚拟租户，限制横向访问其他客户数据 2. **数据流隔离** - 非必要数据（如IP地址）在同步到第三方xi统前进行哈xi或脱敏处理 - 通过网关（如API Gateway）对供应商接口调用实施速率限制（如每秒<10次）和参数校验（如limit max=100） 3. **检测与响应** - 在SIEM中配置规则，监控供应商API异常请求模式（如24小时内单IP请求用户数超过阈值） - 对第三方xi统进行定期红队模拟攻击（如尝试越权访问或爆破API未授权端点） **关键结论**：事件本质是第三方服务权限失控导致的横向暴露，修复需从“最小权限+实时监控+红队验证”三个维度重构供应商安全管控体xi。