Below are cases where updates will be allowed via the stored stored procedure without the caller having update permissions on the table in the other database.
The databases involved have the
DB_CHAINING option set or the 'cross database ownership chaining' option turned on at the server level. In the case of dbo-owned objects, the databases must also the same owner (i.e. dbo user maps to same login) to mainain an unbroken ownership chain.
The stored procedure includes an
EXECUTE AS USER specification and the user (mapped to same login) exists in the other database with update permissions. Note that the database must be
TRUSTWORTHY in order for the
EXECUTE AS context to be honored by other databases so this does not apply in your case.
The stored procedure is signed by a certificate and a user created from that certificate exists in the other database with permissions to update the table.
I see from your comment that 'cross database ownership chaining' was the culprit. This also implies the databases also have the same owner. I suggest you change the database owner for databases where non-sysadmin role members can create dbo-owned objects to mitigate security risk.