<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Lambda on it-learn.io | IT, Networking &amp; Cybersecurity Blog</title><link>https://blog.it-learn.io/tags/lambda/</link><description>Recent content in Lambda on it-learn.io | IT, Networking &amp; Cybersecurity Blog</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Wed, 22 Apr 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://blog.it-learn.io/tags/lambda/index.xml" rel="self" type="application/rss+xml"/><item><title>Serverless Injection: Attacking Lambda Functions Through Event Data</title><link>https://blog.it-learn.io/posts/2026-04-22-serverless-injection-attacking-lambda-through-event-data/</link><pubDate>Wed, 22 Apr 2026 00:00:00 +0000</pubDate><guid>https://blog.it-learn.io/posts/2026-04-22-serverless-injection-attacking-lambda-through-event-data/</guid><description>&lt;p&gt;Serverless functions are not exempt from injection vulnerabilities. The attack surface is different — instead of HTTP request parameters, the injection point is the event payload: the JSON object that arrives from S3, SQS, API Gateway, DynamoDB Streams, SNS, EventBridge, or any of the dozens of other event sources that can trigger a Lambda function.&lt;/p&gt;
&lt;p&gt;The challenge is that developers often apply strict validation to data arriving from external HTTP requests (API Gateway events) but treat data from internal event sources — an S3 event triggered by a bucket upload, an SQS message from another service — as implicitly trustworthy. This trust assumption is exactly what attackers exploit.&lt;/p&gt;</description></item></channel></rss>