Why MySQL performs full table scan if subquery is used in update statement
IN ( SELECT ... ) has always been poorly optimized in MySQL.  There were improvements in 5.6, but it does not seem to cover your case.  File a bug with http://bugs.mysql.com if you like.

It is often better to change to a JOIN since it optimizes better.  (I assume your real query is more involved, and you simplified it for this Forum.)

You can verify whether it does a table scan:

FLUSH STATUS;
perform the operation
SHOW SESSION STATUS LIKE 'Handler%';


Meanwhile, the "rows" in EXPLAIN is pessimistic in some situations.  I would trust the Handler counts when in doubt.  With 15 rows instead of 10, I got (excluding 0 values):

| Handler_commit             | 1     |
| Handler_external_lock      | 4     |
| Handler_read_first         | 1     |
| Handler_read_key           | 18    |
| Handler_read_rnd_next      | 16    |
| Handler_update             | 2     |
| Handler_write              | 2     |


That smells like a tmp table with 2 rows, plus a full scan (maybe twice?) of 15 rows, plus some other miscellany.