While the various security considerations for integrating Chainlink Data Feeds are well documented, such as in this excellent deep dive by Dacian, and often heavily reported during both private and competitive audits, this is a notable gap when considering other widely used Chainlink services.

This article will focus on the security considerations for integrating Chainlink Functions & Automation, demonstrated with findings from a recent Cyfrin private audit for Chainlink Build Program project The Standard. A full list of high and medium severity findings can be found here, along with the full report here.

Note that while the main categories of findings and associated heuristics discussed in this article are around the implementation-specific composition of the two Chainlink services, chaining Automation upkeep calls with the fulfillment of the triggered Functions requests, it remains very pertinent to other codebases both when the services are leveraged in isolation and by virtue of the fact this multi-faceted integration is not an uncommon design pattern to observe.

A Note on Chainlink Services and Reverts

To first elucidate some nuances about the Chainlink Functions and Automation services that both leverage the same shared subscription and billing model, note that:

The Chainlink Automation DON performs the upkeep check every block.
Upkeep transactions are broadcast immediately, save for some latency associated with transaction inclusion and confirmation.
The subscription is billed for every Automation upkeep transaction.
The Chainlink Functions DON reports the status of both off-chain computation and on-chain callback.
The Chainlink Functions DON will only ever attempt to fulfill a given request once.
Only one of the Functions callback response/err parameters will be set to non-zero bytes.
Failed Functions executions will not be retried, so the subscription is billed only once even if the callback reverts.
There exists a five-minute timeout after which a Functions request becomes stale, hence it is not guaranteed that the callback will receive a response.

As we will see below, it is thus imperative to ensure that mission-critical logic contained within the Functions callback, potentially triggered by Automation upkeep, does not revert unless absolutely unavoidable. If it does, this case should be handled gracefully with an optional but highly recommended admin-controlled escape hatch to avoid halting further executions. The flow looks something like this:

1. `checkUpkeep()` called off-chain by Chainlink Automation DON.
2. Upkeep required.
3. `performUpkeep()` called on-chain by Chainlink Automation DON.
4. Chainlink Functions request triggered within upkeep logic.
5. Chainlink Functions DON attempts to fulfill request.
6. Chainlink Functions `fulfillRequest()` callback reverts.
7. Mission-critical logic is not executed, leaving state corrupted.
8. Admin resets corrupted state, allowing execution to resume as normal.

DoS of Core Functionality

With the stage freshly set, let’s consider all the ways to avoid having the fulfillRequest() callback revert:

Do not revert if an error in off-chain computation is reported by the Functions DON (i.e. don’t bubble up err bytes).
Avoid attempting to decode an empty response when there are non-zero err bytes present.
Validate the response against its expected length to ensure that the decoding does not revert.
Avoid reverting if validation of the contents of the API response fails.
Handle reverts from all external calls using try/catch blocks.
Short-circuit if specific inputs would cause other calls to revert.
Be very wary of return data bombs and other gas-exhaustion attacks.
Optionally add an access-controlled admin function to reset critical state.

In this example, upkeep can only be triggered when there are no in-flight requests waiting to be fulfilled. An unhandled revert in AutoRedemption::fulfillRequest would cause execution to end without resetting the required lastRequestId state. Due to the absence of any other method for resetting the state, this therefore results in a denial-of-service on the entire upkeep → callback mechanism.

function performUpkeep(bytes calldata performData) external {
    if (lastRequestId == bytes32(0)) {
        triggerRequest();
    }
}

function fulfillRequest(bytes32 requestId, bytes memory response, bytes memory err) internal override {
    // TODO proper error handling
    // if (err) revert; // @audit - no, don't do this!
    if (requestId != lastRequestId) revert("wrong request"); // @audit - avoid this also!
    ...
    lastRequestId = bytes32(0); // @audit - this will not be reset if execution reverts!
}

Also note that as mentioned above, there is always some small chance that despite a very high degree of reliability the Chainlink Functions DON may not respond if a request becomes stale. Drawing on an excellent example present in the Tunnl smart contracts, this can be handled gracefully by implementing a manual or automated retry mechanism that allows Functions requests to be sent again in the event of failure.

/*
* @notice This function is called in case of Twitter API failure, RPC issue, or any general
* failure in order to manually retry functions request via admins based on status of offer
* @param offerIds The offer Ids to be sent for batch manual retry request
*/
function retryRequests(bytes32[] calldata offerIds) external onlyAdmins {
    for (uint256 i = 0; i < offerIds.length; i++) {
        bytes32 offerId = offerIds[i];

        // Check if the offer is eligible for a retry based on its status
        if (
            s_offers[offerId].status == Status.VerificationFailed ||
            s_offers[offerId].status == Status.VerificationInFlight ||
            s_offers[offerId].status == Status.AwaitingVerification
        ) {
            sendFunctionsRequest(offerId, RequestType.Verification);
        }
        if (
            s_offers[offerId].status == Status.PayoutFailed ||
            s_offers[offerId].status == Status.PayoutInFlight ||
            (s_offers[offerId].status == Status.Active && s_offers[offerId].payoutDate <= block.timestamp)
        ) {
            sendFunctionsRequest(offerId, RequestType.Payout);
        }
    }
}

Heuristic: is it possible for Chainlink Functions & Automation calls to revert? Can an attacker manipulate state to force this case? Is there an escape hatch to reset state in the event of failed requests or other incomplete execution?

More examples: [1, 2, 3, 4, 5, 6].

Insufficient Access Controls

While it may be tempting to overlook access controls on the checkUpkeep() and performUpkeep() functions of AutomationCompatibleInterface given the intention to automate key aspects of a protocol, this is very likely to provide would-be attackers with one or more levers for manipulation. It is also important to note that, without use of the cannotExexute() modifier, both functions allow for state changes when called; therefore, even though checkUpkeep() is used for simulation and subsequent triggering of performUpkeep() by the Chainlink Automation DON, it could also contain state-changing logic. This means it may not be sufficient to add access controls to just one function or the other – always analyse the context and verify the behaviour of both.

In this example, recalling the context from above, upkeep can only be triggered when the lastRequestId state variable is equal to bytes32(0); however, since this state is reset at the end of execution initiated within triggerRequest(), specifically in AutoRedemption::fulfillRequest, this means that upkeep can be repeatedly performed after the previous one has succeeded. Note that this is possible regardless of the trigger condition both due to the absence of access controls and a failure to re-check the trigger condition to prevent execution based on stale or manipulated data when upkeep is actually performed.

function checkUpkeep(bytes calldata checkData) external returns (bool upkeepNeeded, bytes memory performData) {
    (uint160 sqrtPriceX96,,,,,,) = pool.slot0();
    upkeepNeeded = sqrtPriceX96 <= triggerPrice;
}

function performUpkeep(bytes calldata performData) external { // @audit - no access controls!
    if (lastRequestId == bytes32(0)) {
        triggerRequest(); // note: triggers a call to autoRedemption()
    }
}

From here, an attacker can leverage other implementation errors in the logic triggered by the callback to force a revert and permanently disable the functionality. For example, the incorrect calculation of the debt redeemed, as reported here and shown below, causes a panic revert due to underflow when the given vault is fully redeemed but a dust amount of USDs is transferred to the contract beforehand.

function autoRedemption(...) external onlyAutoRedemption returns (uint256 _redeemed) {
    ...
    _redeemed = USDs.balanceOf(address(this)); // @audit - dust amount can be sent to inflate this value!
    minted -= _redeemed; // @audit - meaning this could revert due to underflow if the vault is fully redeemed.
    ...
}

As mentioned above, given that there is no other way to reset lastRequestId, this represents a state from which a non-upgradeable contract cannot recover.

Heuristic: are the AutomationCompatibleInterface functions permissionless? Is the execution of logic within these functions sensitive to on-chain state? Is it problematic if they be called by any account at any time?

More examples: [1].

Unintended/Incomplete Execution

As stated before, the Chainlink Automation DON checks the upkeep condition every block. Once the trigger condition is met and upkeep is required, the DON will send a transaction on-chain. In a sense, this can be thought of as asynchronous execution of a state transition within a finite state machine.

If such a state transition is not completed fully, correctly, or even intentionally, then problems may arise. This scenario could occur in a manner similar to the first example, where unhandled reverts result in an irrecoverable state, or caused through a similar vector in which an attacker additionally leverages incorrect implementation details as in the second example.

In this example, the trigger condition is based on a price oracle that is derived from the instantaneous reserves of a Uniswap v3 pool. As you may have already noted, this oversight can be leveraged by an attacker through manipulation of the pool reserves to trigger upkeep when it is potentially not desired.

function checkUpkeep(bytes calldata checkData) external returns (bool upkeepNeeded, bytes memory performData) {
    (uint160 sqrtPriceX96,,,,,,) = pool.slot0();
    upkeepNeeded = sqrtPriceX96 <= triggerPrice;
}

While I recommend reading the full finding linked above for more details about the potential manipulation and considerations around the maintenance of such a manipulation given the latency of upkeep performance, the repeated triggering of upkeep in this manner could result in the subscription being fraudulently billed to exhaustion.

Heuristic: is every state transition properly accounted for? Can the state be manipulated into an incorrect transition? Is a permissionless call to performUpkeep() safe for all inputs? Should the trigger condition be re-checked when performing upkeep?

More examples: [1, 2].

Request Authentication & Secrets

With increasingly advanced smart contract applications now commonly leveraging additional off-chain infrastructure, it is important to highlight in this final example that great care must be taken to secure both the on-chain and off-chain components. Here, the source constant defined within AutoRedemption is used to execute the corresponding JavaScript code within the Chainlink Functions DON; however, the target API endpoint is exposed without any form of authentication which allows any observer to send requests.

string private constant source =
        "const { ethers } = await import('npm:ethers@6.10.0'); const apiResponse = await Functions.makeHttpRequest({ url: 'https://smart-vault-api.thestandard.io/redemption' }); if (apiResponse.error) { throw Error('Request failed'); } const { data } = apiResponse; const encoded = ethers.AbiCoder.defaultAbiCoder().encode(['uint256', 'address', 'uint256'], [data.tokenID, data.collateral, data.value]); return ethers.getBytes(encoded)";

At a minimum, rate limiting should be implemented to mitigate against coordinated DDoS attacks on the API endpoint. Ideally, authentication should be added to the request using Chainlink Functions secrets.

Heuristic: does the Chainlink Functions request leak sensitive information? Are self-hosted API endpoints sufficiently protected? Is the off-chain infrastructure configured to be resilient to DDoS attacks?

Conclusion

To summarise, when integrating Chainlink Functions and/or Automation:

Unhandled reverts should be avoided at all costs. An attacker should not be able manipulate state to force this case and the application should be designed in such a way to avoid irrecoverable execution. If this is not possible, the contract admin should have access to a permissioned function to reset critical paths.
The execution of callback functions should likely not be permissionless, especially if they are sensitive to on-chain state and/or timing that could be manipulated by an attacker. This includes trigger conditions that should also be resistant to manipulation.
Every state transition should be properly accounted for and trigger conditions should generally be re-checked during execution.
Sensitive off-chain information, such as API endpoints and associated secrets, should be sufficiently protected if exposed on-chain.

That is all for this article. I hope it gives developers and security researchers alike some inspiration when it comes to reviewing the integration of these lesser-discussed Chainlink services. Watch out for a couple of additional findings from this audit related to the Uniswap v3 integration and some tick weirdness that will be explored in a future article!

Chainlink Functions & Automation – A Deep Dive

Table of contents